Am Sonntag, den 10.05.2020, 18:24 -0400 schrieb Dan Eble:
> On May 10, 2020, at 15:36, Jonas Hahnfeld <
> hah...@hahnjo.de
> > wrote:
> > All right, I populated the repository
>
> When I try to fetch from gitlab with https, it prompts me to authenticate.
> It's inconvenient. Is it expected?
This is the second time I send this message.
I did not receive it back the first time, so to be sure.
> -Oorspronkelijk bericht-
> Van: lilypond-devel
>
> Namens Carl Sorensen
> Verzonden: Monday, May 11, 2020 5:43 AM
> Aan: Owen Lamb ; Werner LEMBERG ;
>
> -Oorspronkelijk bericht-
> Van: lilypond-devel
> Namens Joram Noeck
> Verzonden: Monday, May 11, 2020 12:51 AM
> Aan: lilypond-devel@gnu.org
> Onderwerp: Re: migration to GitLab
>
> Hi Dan,
>
> as far as I understand (from experience with other projects), you can clone
>
> -Oorspronkelijk bericht-
> Van: lilypond-devel
> Namens Carl Sorensen
> Verzonden: Monday, May 11, 2020 5:43 AM
> Aan: Owen Lamb ; Werner LEMBERG ;
> lilypond-devel@gnu.org; Federico Bruni
> Onderwerp: Re: Compiling from LilyDev
>
>
> On 5/10/20, 8:50 PM, "lilypond-devel on behalf
On 5/10/20, 8:50 PM, "lilypond-devel on behalf of Owen Lamb"
wrote:
Hi all,
I've hit a couple roadblocks trying to compile LilyPond from LilyDev as per
the instructions on the website(
http://lilypond.org/doc/v2.21/Documentation/contributor/compiling-with-lilydev),
both during the "Preparing
Hi all,
I've hit a couple roadblocks trying to compile LilyPond from LilyDev as per
the instructions on the website(
http://lilypond.org/doc/v2.21/Documentation/contributor/compiling-with-lilydev),
both during the "Preparing the build" step where ../configure is run.
First, the environment
On May 10, 2020, at 18:51, Joram Noeck wrote:
>
> as far as I understand (from experience with other projects), you can
> clone anonymously (and fetch without authentication then).
> If you want to be able to push, you need to authenticate and then you
> also need to authenticate for fetch or
Hi Dan,
as far as I understand (from experience with other projects), you can
clone anonymously (and fetch without authentication then).
If you want to be able to push, you need to authenticate and then you
also need to authenticate for fetch or pull.
A way around that is to use the ssh urls and
On May 10, 2020, at 15:36, Jonas Hahnfeld wrote:
>
> All right, I populated the repository
When I try to fetch from gitlab with https, it prompts me to authenticate.
It's inconvenient. Is it expected?
—
Dan
Am Sonntag, den 10.05.2020, 22:03 +0200 schrieb Han-Wen Nienhuys:
> On Sun, May 10, 2020 at 9:29 PM Jonas Hahnfeld wrote:
> > Am Sonntag, den 10.05.2020, 14:41 -0400 schrieb Dan Eble:
> > > I'm trying to upgrade the LilyDev Dockerfile to use Ubuntu 20.04 and I
> > > get this error when I try to
On Sun, May 10, 2020 at 9:29 PM Jonas Hahnfeld wrote:
>
> Am Sonntag, den 10.05.2020, 14:41 -0400 schrieb Dan Eble:
> > I'm trying to upgrade the LilyDev Dockerfile to use Ubuntu 20.04 and I get
> > this error when I try to build. It's coming from here:
> >
> > # realpath doesn't exist on
As a result of the comment from Dan I revoke all previous patches I did sent
today, and have created a new batch of patches.
Those patches do are smaller, and do not include the to-int() conversions I had
in my previous patches, because further investigation learned that in all cases
it would
Am Sonntag, den 10.05.2020, 20:47 +0200 schrieb Jonas Hahnfeld:
> I've started preparation for migrating to GitLab. There has been no
> activity for the past hours on SourceForge, please keep it that way.
> Write access is still open, but I expect to disable it shortly.
> Likewise for the repo,
Am Sonntag, den 10.05.2020, 14:41 -0400 schrieb Dan Eble:
> I'm trying to upgrade the LilyDev Dockerfile to use Ubuntu 20.04 and I get
> this error when I try to build. It's coming from here:
>
> # realpath doesn't exist on OSX
> realpath() {
> python -c "import os;
symlink sounds like the fastest solution.
On Sun, May 10, 2020 at 8:42 PM Dan Eble wrote:
>
> I'm trying to upgrade the LilyDev Dockerfile to use Ubuntu 20.04 and I get
> this error when I try to build. It's coming from here:
>
> # realpath doesn't exist on OSX
> realpath() {
>
I've started preparation for migrating to GitLab. There has been no
activity for the past hours on SourceForge, please keep it that way.
Write access is still open, but I expect to disable it shortly.
Likewise for the repo, please don't push to Savannah anymore.
I'll keep you posted on the
I'm trying to upgrade the LilyDev Dockerfile to use Ubuntu 20.04 and I get this
error when I try to build. It's coming from here:
# realpath doesn't exist on OSX
realpath() {
python -c "import os; print(os.path.realpath('$1'))"
}
Is there a Right Way to resolve this? Should
On 2020/05/10 15:49:43, Dan Eble wrote:
> This is an area of LilyPond that I don't understand very well, so feel
free to
> ignore this question if the answer should be obvious. This patch
removes a call
> to get_property (stem, "positioning-done") for cross-staff stems, but
doesn't
> add an
This is an area of LilyPond that I don't understand very well, so feel
free to ignore this question if the answer should be obvious. This
patch removes a call to get_property (stem, "positioning-done") for
cross-staff stems, but doesn't add an alternative anywhere. Is
something else already
Dan,
As you already did see, I did not a simple cast, but instead my solution is
raising an error in those cases where a simple cast would change the value
tested.
However, I will follow your suggestion, and break the patch in parts.
I also will pay attention to your particular example, as I
On May 10, 2020, at 08:11, lilyp...@de-wolff.org wrote:
>
> I did replace all implicit casts to an int by a inline function, checking if
> the value is valid, and then casting to int.
>
> Together with my previous patch now all but one compiler warnings are
> solved.
Jaap,
I love the fact
Am Sonntag, den 10.05.2020, 14:30 +0200 schrieb David Kastrup:
> For a while, I've been getting the warning
>
> WARNING: The .setpdfwrite operator has been deprecated and will be
> removed entirely
> in the next release of Ghostscript. The functionality of this
> operator has
writes:
>
>
> Patch to remove warning in flex generated code.
>
>
>
> This patch together with the previous 2 patches I have sent, remove all
> compiler warnings while compiling lilypond on my machine (Debian 64 buster).
Just so that you don't feel like you are being ignored here: we are
Patch to remove warning in flex generated code.
This patch together with the previous 2 patches I have sent, remove all
compiler warnings while compiling lilypond on my machine (Debian 64 buster).
Jaap de Wolff
>From 9cb9dbf8d91194c13a6331ab482b6bc5b2e3895c Mon Sep 17 00:00:00 2001
For a while, I've been getting the warning
WARNING: The .setpdfwrite operator has been deprecated and will be removed
entirely
in the next release of Ghostscript. The functionality of this
operator has
been reduced to increasing the size of the VM threshold.
I did replace all implicit casts to an int by a inline function, checking if
the value is valid, and then casting to int.
Together with my previous patch now all but one compiler warnings are
solved.
Remark: I do not have git rights on the lilypond tree, so someone else
should merge those
> In any case it's not clear to me whether I should prepare for the
> migration today or not. This would be less frustrating if other
> high- volume developers (including but not limited to David,
> Han-Wen, Werner) commented on the plan...
I like it, so please proceed! And thanks for working
*Much* better to read and understand, thanks! LGTM now.
https://codereview.appspot.com/566080043/
Hi,
I solved some compiler warnings.
See attached patch
Jaap de Wolff
0001-Solve-several-compiler-warnings.patch
Description: Binary data
Am Sonntag, den 10.05.2020, 11:59 +0200 schrieb David Kastrup:
> I am running Patchy right now (it's not just this commit but also a few
> by Jonas) but it would make sense if nobody pushed anything afterwards.
Famous last words. In any case, if something gets to the wrong repo or
branch, it's
Han-Wen Nienhuys writes:
> On Sun, May 10, 2020 at 11:57 AM David Kastrup wrote:
>
>> output-distance: set device properties in batch driver file
>>
>> This fixes the output quality of the regtest results.
>>
>> Previously, the code sets a device by doing
>>
>> (png16m)
On Sun, May 10, 2020 at 11:57 AM David Kastrup wrote:
> output-distance: set device properties in batch driver file
>
> This fixes the output quality of the regtest results.
>
> Previously, the code sets a device by doing
>
> (png16m) finddevice
>
> this put a default device
On 2020/05/10 10:03:57, hahnjo wrote:
> > > > yes. I find it easier to reason about and read. It's all inlined
anyway.
> > >
> > > const refs should work the same AFAICS
> >
> > Yes, I know. Do you want me to change this?
>
> Yes, const refs avoid relying on compiler optimizations to remove the
On 2020/05/10 10:00:54, hahnjo wrote:
> On 2020/05/10 09:29:48, hanwenn wrote:
> >
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc
> > File lily/freetype.cc (right):
> >
> >
>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode143
> >
On 2020/05/10 10:02:27, hanwenn wrote:
> On 2020/05/10 10:00:54, hahnjo wrote:
> > On 2020/05/10 09:29:48, hanwenn wrote:
>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode149
> > > lily/freetype.cc:149: return ((Path_interpreter *) user)->moveto
(*to);
> > > On
On 2020/05/10 10:00:54, hahnjo wrote:
> On 2020/05/10 09:29:48, hanwenn wrote:
> >
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc
> > File lily/freetype.cc (right):
> >
> >
>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode143
> >
On 2020/05/10 09:29:48, hanwenn wrote:
>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc
> File lily/freetype.cc (right):
>
>
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode143
> lily/freetype.cc:143: };
> On 2020/05/10 09:16:58, hahnjo
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Sun, May 10, 2020 at 11:37 AM David Kastrup wrote:
>>>
>>> Han-Wen Nienhuys writes:
>>>
>>> > Sorry. I'm fine with the migration going through today.
>>> >
>>> > We'll all be confused for a few days, but given that gitlab is more
>>> >
Han-Wen Nienhuys writes:
> On Sun, May 10, 2020 at 11:37 AM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > Sorry. I'm fine with the migration going through today.
>> >
>> > We'll all be confused for a few days, but given that gitlab is more
>> > standard infrastructure than what
Han-Wen Nienhuys writes:
> On Sun, May 10, 2020 at 11:37 AM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > Sorry. I'm fine with the migration going through today.
>> >
>> > We'll all be confused for a few days, but given that gitlab is more
>> > standard infrastructure than what
On Sun, May 10, 2020 at 11:37 AM David Kastrup wrote:
>
> Han-Wen Nienhuys writes:
>
> > Sorry. I'm fine with the migration going through today.
> >
> > We'll all be confused for a few days, but given that gitlab is more
> > standard infrastructure than what we have, I think we'll figure it
> >
Han-Wen Nienhuys writes:
> Sorry. I'm fine with the migration going through today.
>
> We'll all be confused for a few days, but given that gitlab is more
> standard infrastructure than what we have, I think we'll figure it
> out.
>
> I suggest:
>
> * removing write access to issue tracker from
Le 10/05/2020 à 10:50, Jonas Hahnfeld a écrit :
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
instructions at the time we make the switch. They
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc
File lily/freetype.cc (right):
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode143
lily/freetype.cc:143: };
On 2020/05/10 09:16:58, hahnjo wrote:
> Not sure if FT developers plan to change
Am Sonntag, den 10.05.2020, 11:05 +0200 schrieb Han-Wen Nienhuys:
> On Sun, May 10, 2020 at 10:51 AM Jonas Hahnfeld wrote:
> > In any case it's not clear to me whether I should prepare for the
> > migration today or not. This would be less frustrating if other high-
> > volume developers
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
>> > > instructions at the time we make the switch. They don't
https://codereview.appspot.com/569700043/diff/554040049/lily/include/lazy-skyline-pair.hh
File lily/include/lazy-skyline-pair.hh (right):
https://codereview.appspot.com/569700043/diff/554040049/lily/include/lazy-skyline-pair.hh#newcode30
lily/include/lazy-skyline-pair.hh:30: CW = UP,
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc
File lily/freetype.cc (right):
https://codereview.appspot.com/566080043/diff/560020046/lily/freetype.cc#newcode143
lily/freetype.cc:143: };
Not sure if FT developers plan to change this interface at some point.
In other
On Sun, May 10, 2020 at 10:51 AM Jonas Hahnfeld wrote:
>
> 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
> > > > instructions at the
On Sun, May 10, 2020 at 10:38 AM wrote:
>
> On 2020/05/09 20:38:12, hanwenn wrote:
> > it's separate because it causes formatting changes. I like to keep the
> bugfixes
> > and performance fixes separate. (Performance fixes should not cause
> regtest
> > differences)
>
> Sounds fair, but I don't
Hi Valentin
On Sun, May 10, 2020 at 10:13:04AM +0200, Valentin Villenave wrote:
> Greetings,
>
> could anyone give me a hint as to where dynamics alignment is handled?
> As far as I can see, the self-alignment-interface functions are not
> used by the (formerly new) dynamic-engraver; and AFAICS
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
> > > instructions at the time we make the switch. They don't have to be
> > > perfect (the CG
On 2020/05/08 15:49:18, lemzwerg wrote:
>
https://codereview.appspot.com/569700043/diff/573820043/lily/freetype.cc
> File lily/freetype.cc (right):
>
>
https://codereview.appspot.com/569700043/diff/573820043/lily/freetype.cc#newcode129
> lily/freetype.cc:129: else if (ctags[j] & 1)
> 1 →
On 2020/05/09 20:38:12, hanwenn wrote:
> it's separate because it causes formatting changes. I like to keep the
bugfixes
> and performance fixes separate. (Performance fixes should not cause
regtest
> differences)
Sounds fair, but I don't understand the relation of the two changes:
- Both touch
Greetings,
could anyone give me a hint as to where dynamics alignment is handled?
As far as I can see, the self-alignment-interface functions are not
used by the (formerly new) dynamic-engraver; and AFAICS the following
diff doesn’t break compiling nor change any of the regtests:
diff --git
On 2020/05/09 18:25:03, lemzwerg wrote:
>
https://codereview.appspot.com/560030044/diff/557800043/scm/define-context-properties.scm#newcode609
> scm/define-context-properties.scm:609: merge rests when this is set to
true.")
> While you are at it, please fix indentation (i.e., no indentation for
Thank you for looking at this!
https://codereview.appspot.com/554030043/diff/583870043/lily/note-head.cc
File lily/note-head.cc (right):
https://codereview.appspot.com/554030043/diff/583870043/lily/note-head.cc#newcode114
lily/note-head.cc:114: if (stem and ! ly_scm2bool (get_property (stem,
Reviewers: lemzwerg, thomasmorley651,
Message:
On 2020/05/09 20:17:09, thomasmorley651 wrote:
> Not sure about chordNameExceptionsFull and chordNameExceptionsPartial.
> I thought our deprecating policy would be to wait for 1 or even 2
stable
> versions before deleting from source.
Actually, all
58 matches
Mail list logo
