Jonas Hahnfeld writes:
> Am Samstag, den 09.05.2020, 16:11 -0400 schrieb Dan Eble:
>> On May 9, 2020, at 15:13, David Kastrup wrote:
>> > Carl Sorensen writes:
>> > > ->CS At any rate, I think that we should have appropriate CG
>> > > instruction
to have all that before,
it increases the workload for those preparing the migration and they
have to guess.
I totally agree that the CG should reflect the new workflows. But at
the time we do the switch, those new workflows are still in flux.
--
David Kastrup
ng options are there? I think it makes sense for
the non-developer access to keep referring/pointing to Savannah since I
consider it a resource with more long-term dependable availability.
--
David Kastrup
David Kastrup writes:
> David Kastrup writes:
>
>> Han-Wen Nienhuys writes:
>>
>>> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>>>
>>>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>>>> > I a
on your proposed alternative to
>> https://codereview.appspot.com/577720043/ . Or did I miss an update on
>> that topic?
>
> https://sourceforge.net/p/testlilyissues/issues/5895/
> https://codereview.appspot.com/547920045
> ?
Thanks.
--
David Kastrup
My replies have a tend
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>>
>>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>>> > I am currently digging back and forth regarding implementati
Han-Wen Nienhuys writes:
> On Tue, May 5, 2020 at 5:49 PM Jonas Hahnfeld wrote:
>>
>> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>> > I am currently digging back and forth regarding implementation of our
>> > Smobs (Scheme objects) and
David Kastrup writes:
> Dan Eble writes:
>
>> On May 5, 2020, at 13:37, David Kastrup wrote:
>>>
>>> What I have ready-to-use is something that stores like an SCM value but
>>> behaves like a Smob pointer with regard to -> and * usage.
>>
>
Dan Eble writes:
> On May 5, 2020, at 13:37, David Kastrup wrote:
>>
>> What I have ready-to-use is something that stores like an SCM value but
>> behaves like a Smob pointer with regard to -> and * usage.
>
> Oh. I believe I have some of that too. Excerpt:
>
r decision of the tools we use.
>
> Due to lack of other responses, I went ahead and created the repository
> (see above). I'll still wait a few days for others to voice their
> opinions before posting some final questions and proposing the actual
> migration.
I think that
Dan Eble writes:
> On May 5, 2020, at 11:09, David Kastrup wrote:
>> I'd like to come up with an allocator/container programming model
>> comparatively similar to the STL one so that one could mostly steal the
>> implementations and "just" add the required S
Hans Åberg writes:
>> On 5 May 2020, at 17:09, David Kastrup wrote:
>>
>> One reason is that we want to get rid of finalisers particularly in
>> connection with the Boehm GC. Finalisers are called when garbage is
>> collected, the collection of garbage
Jonas Hahnfeld writes:
> Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup:
>> I am currently digging back and forth regarding implementation of our
>> Smobs (Scheme objects) and garbage collection and STL, and I think I am
>> converging on the realisation that
nd keeping it work would be
robust and dependable (and efficient) enough to make this a really good
idea.
--
David Kastrup
ose is here.
I don't see that it is frequent. You'll find it mostly in scm/midi.scm
and if you use git blame on that, you'll find that this style in this
file significantly precedes the introduction of define-session.
You'd have to ask Han-Wen and Jan for their respective motivations here.
--
David Kastrup
745, apparently.
>From 2013. It's sobering that 2.18 does not yet contain it.
--
David Kastrup
days is SCM. And for looking up a token ID from
an SCM symbol, Guile has hashtables, and we also habe Scm_hashtable.
--
David Kastrup
ages also depend on
individuals' environments.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Apr 24, 2020 at 3:15 PM David Kastrup wrote:
>>
>
>> > If you want me to use "auto" instead of
>> > "vector::const_iterator", can you just point to the line in
>> > the code and say "could you u
ugh the
code that is important. Humans are worth consideration as well.
> If you want me to use "auto" instead of
> "vector::const_iterator", can you just point to the line in
> the code and say "could you use auto instead of an iterator here"?
Wouldn't "everywhere" be sort of obvious?
> https://codereview.appspot.com/583750043/
--
David Kastrup
effect known from
Quicksort.
Now that's not at issue with this patch. What I point out here is that
moving from one STL container to another STL container is a standard
programming technique that is _exactly_ why the STL library has
iterators, and C++11 has for loops that can easily iterate through
containers in sequence without even requiring convoluted iterator
declarations. So there is just no point in not doing this in a manner
where it isn't hardcoding one container type throughout.
--
David Kastrup
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> At that day I was having one patchy run after the other and I did go
>> through the log files to indicate the failed file and the error message.
>
> Yep, and I asked for additional info both on the tracker a
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 22:16 +0200 schrieb David Kastrup:
>> pkx1...@posteo.net
>> writes:
>>
>> > Hello,
>> >
>> > On 19/04/2020 17:53, David Kastrup wrote:
>> > > v.villen...@gmail.com
>> > &
pkx1...@posteo.net writes:
> Hello,
>
> On 19/04/2020 17:53, David Kastrup wrote:
>> v.villen...@gmail.com writes:
>>
>>> On 2020/04/11 09:44:26, Valentin Villenave wrote:
>>>> What could be the cause?
>>> So, pushed as
>>&g
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 20:03 +0200 schrieb David Kastrup:
>> David Kastrup <
>> d...@gnu.org
>> > writes:
>>
>> > David Kastrup <
>> > d...@gnu.org
>> > > writes:
>> >
>> > > D
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> mkstemp! does not generate a string. It overwrites an existing string
>> in-place, and that's bad news for a literal string.
>
> Yes, it overwrite the string,
You can/must not override a literal string.
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> You need (mkstemp! (string-copy "...
>> because mkstemp! overrides the string.
>
> Why, yes. What I want to copy is precisely the mkstemp-generated
> string. What did I miss?
mkstemp! does not generat
David Kastrup writes:
> David Kastrup writes:
>
>> David Kastrup writes:
>>
>>> Valentin Villenave writes:
>>>
>>>> On 4/19/20, David Kastrup wrote:
>>>>> Note that the delete-file instructions are executed while the book is
David Kastrup writes:
> David Kastrup writes:
>
>> Valentin Villenave writes:
>>
>>> On 4/19/20, David Kastrup wrote:
>>>> Note that the delete-file instructions are executed while the book is
>>>> being read in while markup is typeset when t
David Kastrup writes:
> Valentin Villenave writes:
>
>> On 4/19/20, David Kastrup wrote:
>>> Note that the delete-file instructions are executed while the book is
>>> being read in while markup is typeset when the books are being processed
>>> at the end
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> ERROR: In procedure mkstemp!:
>> string is read-only: "kaka-XX"
>
> Could the following help?
>
> diff --git a/input/regression/font-name-add-files.ly
> b/input/regression/font-name-add
Valentin Villenave writes:
> On 4/19/20, David Kastrup wrote:
>> Note that the delete-file instructions are executed while the book is
>> being read in while markup is typeset when the books are being processed
>> at the end of the input file.
>
> Yes, it looked compl
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 19:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> > > pat...@gnu.org
>>
Jonas Hahnfeld writes:
> Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> pat...@gnu.org
>> writes:
>>
>> > 16:36:18 (UTC) Begin LilyPond compile, previous commit at
>> > 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > 16:
> File
> "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
> line 266, in runner
> raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command,
> this_logfilename))
> FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
> See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
That's again font-name-add-files.ly .
--
David Kastrup
spot.com/557640051/
Breaks my patchy again. Whose patchy was comfortable moving it from
staging to master?
--
David Kastrup
to downgrade Gitlab's
evaluation because Gitlab is not overly interested in addressing a
number of issues for people bothered above average about software
freedom aspects.
It still seems that at the current point of time our attempt at
balancing priorities would lean towards using Gitlab as a hosted
instance.
--
David Kastrup
> 3: https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg00249.html
> 4: https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg01114.html
> 5: https://lists.gnu.org/archive/html/lilypond-devel/2020-02/msg01134.html
> 6: https://libreplanet.org/wiki/Fsf_2019_forge_evaluation
> 7: https://communityblog.fedoraproject.org/making-a-git-forge-decision/
>
--
David Kastrup
Jonas Hahnfeld writes:
> Am Samstag, den 11.04.2020, 15:33 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Hi all,
>> >
>> > following removal of dev/translation-* branches, I took a closer look
>> > at stale branches. I think
into
> stable.
Without editing. We aren't going to pick large-scale code passages from
master into stable, and frankly, the ability to cherry-pick into stable
has not exactly governed development in master recently a whole lot.
--
David Kastrup
y a
> macro for performance reasons.
That is a red herring since nobody complains about macro calls looking
like function calls: they always do. The problem for understanding is
that this macro call looks like a member function call.
> For thinking about the readability of the source code at the caller
> side, it is better that it remains as a method.
But it isn't a method. It is a macro.
--
David Kastrup
Carl Sorensen writes:
> On 4/13/20, 6:17 AM, "lilypond-devel on behalf of David Kastrup"
> d...@gnu.org> wrote:
>
> It looks to me like we have only two people who have weighed in on the patch:
> the author (David K.) and one reviewer (Han-Wen). Since we have
ccess of such experiments before they are done, but there is
no point in blocking them either.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
here is what more or less came out as the
best-liked alternative with least impact on code readability serving
this purpose. So a different resolution requires a different proposal,
and general agreement that this is also an acceptable way of writing
things.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup wrote:
>>
>>> > the reason being that it is better if the source code looks like plain
>>> C++,
>>> > even though they might actually be
no
qualms mixing up print forms to be read back into Python and actual uses
of strings in a manner that luckily happens to work in Python2" kind of
diagnosis, though it's completely out of my region of expertise. Could
be that the designers of Python rather than its users deserve part of
the blame here. No idea.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Fri, Apr 10, 2020 at 1:07 PM David Kastrup wrote:
>> > * memory use: each SCM value takes 8 bytes, and there are 416 grob
>> > properties today, for a total of 3328 bytes. Morgenlied is single page
>> > of music and has 3704 grobs. So
riting any of it in-place.
I'll readily agree that there is a disconcerting large set of other
apparently semi-dead branches by living people, most of them likely
unaware of what they left lying there. There may be some point in going
through and mailing them about what they think best to do here.
--
David Kastrup
ing (partially) unwritten code based on an incomplete
understanding in a handwaving discussion.
It is more efficient to discuss objections of the "you haven't thought
this through" kind on working code.
Nothing in this patch here enforces picking a particular route. It is
just paving
ivil liability, but I am not sure about the criminal
one.
--
David Kastrup
able prerelease phase, this will hopefully
settle comparatively fast into something more amenable.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Thu, Apr 9, 2020 at 9:36 AM wrote:
>> Waiting:
>>
>> 5874 Remove all uses of markup macro from scm/*.scm - David Kastrup
>> https://sourceforge.net/p/testlilyissues/issues/5874
>> http://codereview.appspot.com/575930043
>
Jonas Hahnfeld writes:
> Hi David,
>
> I think these have gone via translation to master, so safe to delete?
I think so.
--
David Kastrup
1 (one)
> translator. According to the description, Timing_translator is an
> engraver despite the name.
No, it's also used in \midi .
--
David Kastrup
p issue to fix the problem,
or just revert the problematic commit for now. I lean towards the
latter, to be honest.
--
David Kastrup
llow suggestions for how to upgrade distributions. There is also
the more explicit
sudo update-manager -d
but it tends to offer updates to the newest release (possibly
prerelease) rather than the latest stable.
--
David Kastrup
Valentin Villenave writes:
> On 4/5/20, David Kastrup wrote:
>> Valentin Villenave writes:
>>> It should be available in the next LSR database dump (but there’s at
>>> least one file in the Japanese version that depends on it, so the name
>>> w
e
was planning to do tomorrow afternoon), but he'll likely run into this
road block tomorrow.
Pity.
--
David Kastrup
Valentin Villenave writes:
> On 4/5/20, David Kastrup wrote:
>> So perhaps changing the name of that snippet
>> in the LSR would be a good idea.
>
> Hi, I just changed it to
> customized-drum-notation-in-printed-and-MIDI-output.ly (and I reworded
> the doc string
pattern *-midi.ly which applies here. So perhaps
changing the name of that snippet in the LSR would be a good idea. Just
swapping "layout" and "midi" in the name would be sufficient, but maybe
a somewhat more concise name would be possible?
--
David Kastrup
do
git reset --hard HEAD~1
to remove the commit. It's also likely that some setting of
export LANG=en_US.UTF-8
or similar might work, but that's not a given. The particular
invocation that should do the trick is system dependent.
--
David Kastrup
special chars
> once in a while in case it allows to verify that it doesn’t trigger
> any weird behavior?)
I think the names of committers will sometimes make sure of that.
--
David Kastrup
David Kastrup writes:
> Valentin Villenave writes:
>
>> On 4/3/20, David Kastrup wrote:
>>> Anybody have an idea whose Patchy pushed the following:
>>> commit f5f907599ce88d3d610483fa42fa78be12f53d2e
>>
>> Uh, I did push it onto staging after the usua
Valentin Villenave writes:
> On 4/3/20, David Kastrup wrote:
>> Anybody have an idea whose Patchy pushed the following:
>> commit f5f907599ce88d3d610483fa42fa78be12f53d2e
>
> Uh, I did push it onto staging after the usual review process. Could
> that really be what b
David Kastrup writes:
> David Kastrup writes:
>
>> pkx166h writes:
>>
>>> Hello,
>>>
>>> I cannot run a make check from current master.
>>>
>>> --snip..
>>>
>>> no source for input/regression/midi/out-test/seque
David Kastrup writes:
> pkx166h writes:
>
>> Hello,
>>
>> I cannot run a make check from current master.
>>
>> --snip..
>>
>> no source for input/regression/midi/out-test/sequence-name-scoping-1.midi
>> no source for input/regression/midi/
commit f5f907599ce88d3d610483fa42fa78be12f53d2e (origin/staging, origin/master,
origin/HEAD, test-staging)
Author: Valentin Villenave
Date: Thu Apr 2 11:53:37 2020 +0200
Web: update CG instructions, `attic’ page and THANKS for 2.18
I'll start mine now to get another data point.
--
David Kastrup
Simon Albrecht writes:
> Let's be honest, they really had to get their stuff together to keep
> any ground all against Dorico.
I think they may still have the higher ground. But Dorico is moving
much faster.
LilyPond is like Switzerland. High ground, but nobody goes there.
--
Da
Dan Eble writes:
> On Mar 29, 2020, at 14:46, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>>>
>>>> Anybody can think of a holdup?
>>>
>>> convert-ly is broken:
Dan Eble writes:
> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>
>> Anybody can think of a holdup?
>
> convert-ly is broken:
>
> find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
> Traceback (most recent call last):
> File &q
Jean-Charles Malahieude writes:
> Le 29/03/2020 à 18:59, David Kastrup a écrit :
>> Jean-Charles Malahieude writes:
>>>
>>> But, please, pick up the po files I mentioned (ca, da, de, eo, es, fr,
>>> it, ja, nl, sv) which are in advance on stable/2.20. As
Dan Eble writes:
> On Mar 29, 2020, at 14:46, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>>>
>>>> Anybody can think of a holdup?
>>>
>>> convert-ly is broken:
Dan Eble writes:
> On Mar 29, 2020, at 11:54, David Kastrup wrote:
>>
>> Anybody can think of a holdup?
>
> convert-ly is broken:
>
> find . -name '*.ly' -print0 | xargs -0 convert-ly -d -e -l WARN
> Traceback (most recent call last):
> File &q
Werner LEMBERG writes:
>> Anybody can think of a holdup?
>
> No holdup, but I would like to see an LSR import to synchronize
> documentation with snippets.
I think that's standard as part of the release procedure?
--
David Kastrup
Jean-Charles Malahieude writes:
> Le 29/03/2020 à 17:54, David Kastrup a écrit :
>> [Repeat message since I got the address of translations wrong]
>> I see that translation-status is in master. The web site is still
>> getting fixed (including MacOSX download links), so
f a holdup?
--
David Kastrup
Jean-Charles Malahieude writes:
> Le 26/03/2020 à 17:11, David Kastrup a écrit :
>> Because once the big announcements are made, we want people to
>> actually
>> be able to work with what they find on the web page.
>> We can release 2.21.0 prior to that, of course, si
actually
be able to work with what they find on the web page.
We can release 2.21.0 prior to that, of course, since the web page
updates are (I think) independent from releases.
Thoughts?
--
David Kastrup
; IOError: ('http error', 401, 'Unauthorized', instance at 0x7f8715613370>)
>
>
> Traceback attached. What am I doing wrong?
The question is rather what git-cl is doing wrong. This is some fallout
from SourceForge changes (and/or our move from Google Code to there)
that nobody has gotten around to get fixed yet.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Wed, Mar 25, 2020 at 4:12 PM David Kastrup wrote:
>>
>> hanw...@gmail.com writes:
>>
>> > Reviewers: lemzwerg,
>> >
>> > Message:
>> > On 2020/03/22 05:51:34, lemzwerg wrote:
>> >> LGT
Han-Wen Nienhuys writes:
> On Wed, Mar 25, 2020 at 8:15 PM David Kastrup wrote:
>> >> We don't push until the status becomes Push. Countdown is a last
>> >> chance for reviewers to comment.
>> >
>> > Sorry, I saw Valentin had pushed his, so I
ted action (like when other
important changes depend on it).
But doing so without updating issue status and without giving some
feedback with regard to the reasons for urgency is, if nothing else,
quite impolite towards the people who have to pick up the bits
afterwards and sort them into place.
--
David Kastrup
be unprecedented, so the cost of implementing such a
policy would be considerably more moderate than if we had to do it from
scratch.
--
David Kastrup
Francisco Vila writes:
> El 24/3/20 a las 21:58, David Kastrup escribió:
>>> Thanks, I patched it up.
>> Partly. Several download links now contain b'...' visibly.
>>
> Unrelated. I saw this in my local build before the sizes script.
Oh, I didn't ev
ample{R}. Their duration is entered
@example is not an in-text command but rather an environment.
Backing out the respective commit from staging.
All the best.
--
David Kastrup
Dan Eble writes:
> On Mar 23, 2020, at 17:10, David Kastrup wrote:
>>
>> Dan Eble writes:
>
>>> As far as I'm concerned, we could just declare 3.1 to be the new
>>> preferred version. I'm not sure whether that would inconvenience
>>> a
Dan Eble writes:
> On Mar 22, 2020, at 17:04, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> Did you use astyle 2.04 or another version? I built 2.04 from source
> ...
>> 3.1. I am afraid that I may have updated my system since the review,
&
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> The website uses scripts that aren't directly checked out from
>> savannah, so you can't directly compromise the webserver through code
>> commits.
>>
>> I can update the scripts.
>
> A
free expressions (namely quoted lists) and returns the last one which is
(define q "i am Q\n")
This then gets evaluated at run time, defining q .
You probably wanted something like
`(begin (define p ...) (define q ...))
as your body (and return expression) instead.
> (my-macro-old 1 2)
> (my-macro-new 1 2)
> (display x1)
> (display x2)
> (display q)
> (display p)
>
>
> thanks,
--
David Kastrup
Dan Eble writes:
> On Mar 21, 2020, at 11:26, David Kastrup wrote:
>> it got a bit lost in other things, but I think I would want to run
>> fixcc.py right now, reformatting the C++ stuff (it doesn't help with the
>> conventions for template arguments but there are com
think it’s rather
> “building every .o file every time a single .h file is changed” …
It should depend on just what .h file is changed. Some are included by
a whole lot of C files.
--
David Kastrup
ou are suddenly
> talking about fixscm. Is it about cc files, or scm files, or both?
This is about cc files, but scm files are due as well. They will take a
bit more preparation and a separate issue/patch.
--
David Kastrup
xscm commit actually reverts usefully on master.
But maybe not that many patches are in the queue right now.
Ok for me to go ahead, say tomorrow?
--
David Kastrup
ter's script
now.
Thanks!
--
David Kastrup
now and will be included in the next
unstable release.
--
David Kastrup
David Kastrup writes:
> Zone Dremik writes:
>
>> Thank you David, Marnen, David and Carl for your excellent
>> suggestions and helpful examples. (I will definitely be using more
>> variables in the future.)
>> For the convert.ly issue, your recommendations inspir
ine.)
Yes, overrides and reverts are properly converted. It's the naked
assignments that seemed too indistinctive to warrant a generic rule for
the conversion (there was one used for one-shot conversion of LilyPond's
own documentation where one can keep the effects in check).
I have it on my to-do list to do something here for the sake of 2.20.1,
but I'm currently laboring on getting 2.21.0 out first: that's also
urgent.
--
David Kastrup
ic web files? That might make it more straightforward for
the translations to arrive at a uniform strategy since they then could
just copy what the English version does?
--
David Kastrup
David Kastrup writes:
> Marnen Laibow-Koser writes:
>
>> On Wed, Mar 18, 2020 at 12:18 PM Zone Dremik wrote:
>>
>>> It was quite a few years ago that copied this code sample from the
>>> LilyPond Notation Reference v2.18.2 webpage:
>>>
>>>
about it. D’oh! So I guess this is under the
> category of “known issues in convert-ly” rather than “broken build”. Sorry
> for the inconvenience!
More like "should have known issues in convert-ly". Analysis of what
decisions have led there just came up yesterday. There likely is going
to be a fix in 2.20.1 but I cannot yet vouch what.
--
David Kastrup
501 - 600 of 6189 matches
Mail list logo
