On Mar 12, 2020, at 08:36, Kevin Barry wrote:
>
>> Would docker give us this 'proverbial canary' or would it turn into
>> 'worksforme' when someone tried to build their own version of LP on a
>> vanilla base of Linux?
>>
> Docker would eliminate 'worksforme' type issues yes.
The direction of t
Am Do., 12. März 2020 um 16:22 Uhr schrieb Mats Bengtsson
:
>
>
> On 2020-03-12 16:17, Mats Bengtsson wrote:
> >
> > On 2020-03-12 14:39, Jonas Hahnfeld wrote:
> >> I did test some more advanced files than "{ c' }", but apparently not
> >> complicated enough. I think this one actually has the same
Reviewers: ,
Description:
Add #f to format in lilypond-book.itely
In the defiition of oly:create-toc-file a simple string is wished
for the local outfilename.
Thus add #f after format in:
(outfilename (format "~a.toc" output-name))
Please review this at https://codereview.appspot.com/553690043/
Am Donnerstag, den 12.03.2020, 21:26 + schrieb Trevor:
>
> Jonas, you wrote 12/03/2020 20:57:00
>
> > Am Donnerstag, den 12.03.2020, 20:45 + schrieb Trevor:
> > > I couldn't get convert-ly to work in Frescobaldi - not sure why yet.
> >
> > The mingw archive doesn't contain a Python inte
Jonas, you wrote 12/03/2020 20:57:00
Am Donnerstag, den 12.03.2020, 20:45 + schrieb Trevor:
I couldn't get convert-ly to work in Frescobaldi - not sure why yet.
The mingw archive doesn't contain a Python interpreter, so you'd need
this separately on Windows. As far as I remember, GUB
Am Donnerstag, den 12.03.2020, 20:45 + schrieb Trevor:
>
> Mats wrote12/03/2020 19:35:09
> > On 3/12/20 6:02 PM, Jonas Hahnfeld wrote:
> > > Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
> > > > I've tried compiling several of my files running this version of yours
> > > > inside
Mats wrote12/03/2020 19:35:09
On 3/12/20 6:02 PM, Jonas Hahnfeld wrote:
Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
I've tried compiling several of my files running this version of yours inside
Frescobaldi on my Windows 10 system. All worked fine except one. Here's
a MWE whi
On 3/12/20 6:02 PM, Jonas Hahnfeld wrote:
Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
I've tried compiling several of my files running this version of yours inside
Frescobaldi on my Windows 10 system. All worked fine except one. Here's
a MWE which shows the fault I found:
\ver
On 3/12/2020 8:43 AM, Jonas Hahnfeld wrote:
The mingw executable now also
works under wine, but it'd be great if you could test the full version
(and possibly other large scores) on your system. The link is:
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12
I'll give it a try,
LGTM now, thanks!
https://codereview.appspot.com/565750043/diff/557620047/scm/define-music-types.scm
File scm/define-music-types.scm (right):
https://codereview.appspot.com/565750043/diff/557620047/scm/define-music-types.scm#newcode685
scm/define-music-types.scm:685: . ((description . "A transit
>
>
> I say that having a developer monoculture doesn't buy as anything since
> we still need to provide for a multitude of users.
>
We are talking about testing builds right? If a user gets as far as "I need
to test changes I made to the source code" then surely it would be better
to have somethi
Jonas, you wrote
I've just finished building anew, please give
https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
try. Or rebuild with the updated scripts 😉
I've tried compiling several of my files running this version of yours
inside
Frescobaldi on my Windows 10 system. All
Kevin Barry writes:
>>
>>
>> Frankly, I am more sympathetic to "worksforme" discussions among
>> developers than telling users "worksforme". Where is the point in being
>> able to tell users that no developer will reproduce their problem?
>>
>> I'd rather have an error popping up for at least so
Am Donnerstag, den 12.03.2020, 16:57 + schrieb Trevor:
> Jonas, you wrote
> > I've just finished building anew, please give
> > https://github.com/hahnjo/lilypond-binaries/releases/tag/2020-03-12 a
> > try. Or rebuild with the updated scripts 😉
> I've tried compiling several of my files running
>
>
> Frankly, I am more sympathetic to "worksforme" discussions among
> developers than telling users "worksforme". Where is the point in being
> able to tell users that no developer will reproduce their problem?
>
> I'd rather have an error popping up for at least some developers than
> for none
Am Donnerstag, den 12.03.2020, 17:30 +0100 schrieb Mats Bengtsson:
> On 2020-03-12 16:41, Jonas Hahnfeld wrote:
> > Am Donnerstag, den 12.03.2020, 16:17 +0100 schrieb Mats Bengtsson:
> > > I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on a
> > > reasonably large project (some
On 2020-03-12 16:41, Jonas Hahnfeld wrote:
Am Donnerstag, den 12.03.2020, 16:17 +0100 schrieb Mats Bengtsson:
I did a quick test of the lilypond-linux-x86_64-full.tar.gz version on a
reasonably large project (some 80+ page output string quartet score) and
it runs without any error messages and
Kevin Barry writes:
> On Thu, 12 Mar 2020 at 12:48, wrote:
>> I'll defer you to Jonas' reply to this thread just after yours.
>>
>> I'm all for conistent build envs but at least make sure your testing
>> is actually ... err testing what it should be testing.
>>
>> Containers don't protect agains
Am Donnerstag, den 12.03.2020, 16:17 +0100 schrieb Mats Bengtsson:
> On 2020-03-12 14:39, Jonas Hahnfeld wrote:
> > I did test some more advanced files than "{ c' }", but apparently not
> > complicated enough. I think this one actually has the same root case as
> > Karlin reported: I traced this ba
On 2020-03-12 16:17, Mats Bengtsson wrote:
On 2020-03-12 14:39, Jonas Hahnfeld wrote:
I did test some more advanced files than "{ c' }", but apparently not
complicated enough. I think this one actually has the same root case as
Karlin reported: I traced this back to the garbage collector free
On 2020-03-12 14:39, Jonas Hahnfeld wrote:
I did test some more advanced files than "{ c' }", but apparently not
complicated enough. I think this one actually has the same root case as
Karlin reported: I traced this back to the garbage collector freeing
objects prematurely. Apparently it's not
Am Mittwoch, den 11.03.2020, 19:17 +0100 schrieb Jonas Hahnfeld:
> Am Mittwoch, den 11.03.2020, 11:38 -0500 schrieb Karlin High:
> > On Wed, Mar 11, 2020 at 10:56 AM Jonas Hahnfeld <
> > hah...@hahnjo.de
> >
> > > wrote:
> > > Please let me know if something doesn't work at all
> >
> > That sound
Am Donnerstag, den 12.03.2020, 14:18 +0100 schrieb Federico Bruni:
> Il giorno mer 11 mar 2020 alle 16:56, Jonas Hahnfeld <
> hah...@hahnjo.de
> >
> ha scritto:
> > This is _not_ (yet) a proposal to switch over, but rather my ideas
> > about a possible replacement. So take this as a request for fe
Il giorno mer 11 mar 2020 alle 16:56, Jonas Hahnfeld
ha scritto:
This is _not_ (yet) a proposal to switch over, but rather my ideas
about a possible replacement. So take this as a request for feedback
and testing as well as general discussion.
I've just made a test and was able to build the Li
On Thu, 12 Mar 2020 at 12:48, wrote:
> I'll defer you to Jonas' reply to this thread just after yours.
>
> I'm all for conistent build envs but at least make sure your testing is
> actually ... err testing what it should be testing.
>
> Containers don't protect against that.
A docker container i
On 12/03/2020 12:36, Kevin Barry wrote:
Would docker give us this 'proverbial canary' or would it turn into
'worksforme' when someone tried to build their own version of LP
on a
vanilla base of Linux?
Docker would eliminate 'worksforme' type issues yes
And yet ... isn't t
Am Donnerstag, den 12.03.2020, 11:32 +0100 schrieb Han-Wen Nienhuys:
> On Thu, Mar 12, 2020 at 10:37 AM <
> pkx1...@posteo.net
> > wrote:
> > Hello
> >
> > What exactly am I supposed to be testing?
> >
> > With or without make check?
> >
> > I am struggling with all this 'back and forth' and wit
On 2020/03/12 10:10:23, hahnjo wrote:
> On 2020/03/12 10:03:22, dak wrote:
> > Patch needs work (whether it contains a problem itself or triggers a
> > preexisting one that needs to be fixed in order for the patch to go
ahead),
> but
> > it was caught before the problem affected everyone.
>
> I th
>
>
> Would docker give us this 'proverbial canary' or would it turn into
> 'worksforme' when someone tried to build their own version of LP on a
> vanilla base of Linux?
>
Docker would eliminate 'worksforme' type issues yes.
>
On 12/03/2020 10:32, Han-Wen Nienhuys wrote:
On Thu, Mar 12, 2020 at 10:37 AM wrote:
Hello
What exactly am I supposed to be testing?
With or without make check?
I am struggling with all this 'back and forth' and with patches getting
created and tested by different people (worksforme, doesn
On 2020/03/12 12:06:06, davidsg wrote:
> Rename to vowel-transition-event
Trying again with the name 'vowel transition' (sustained consonants are
mentioned explicitly in the docs). Perhaps this is an OK compromise?
Updated docs accordingly and added a couple of regtests, including one
documen
Han-Wen Nienhuys writes:
> On Thu, Mar 12, 2020 at 10:37 AM wrote:
>>
>> Hello
>>
>> What exactly am I supposed to be testing?
>>
>> With or without make check?
>>
>> I am struggling with all this 'back and forth' and with patches getting
>> created and tested by different people (worksforme, do
On Thu, Mar 12, 2020 at 10:37 AM wrote:
>
> Hello
>
> What exactly am I supposed to be testing?
>
> With or without make check?
>
> I am struggling with all this 'back and forth' and with patches getting
> created and tested by different people (worksforme, doesn't work for me
> etc.).
This is ex
On 2020/03/12 10:03:22, dak wrote:
> Patch needs work (whether it contains a problem itself or triggers a
> preexisting one that needs to be fixed in order for the patch to go
ahead), but
> it was caught before the problem affected everyone.
I think it already affects everyone: Current master fail
On 2020/03/12 09:52:31, hahnjo wrote:
> On 2020/03/12 09:33:43, hahnjo wrote:
> > On 2020/03/12 09:22:09, dak wrote:
> > > On 2020/03/12 08:01:03, hahnjo wrote:
> > > > This looks like bash-ism which might explain why it works for
Han-Wen and
> > me.
> > > I
> > > > agree with him that disabling th
On 2020/03/12 09:33:43, hahnjo wrote:
> On 2020/03/12 09:22:09, dak wrote:
> > On 2020/03/12 08:01:03, hahnjo wrote:
> > > This looks like bash-ism which might explain why it works for
Han-Wen and
> me.
> > I
> > > agree with him that disabling the local-test invocation in
GNUmakefile.in is
> > > p
Hello
What exactly am I supposed to be testing?
With or without make check?
I am struggling with all this 'back and forth' and with patches getting
created and tested by different people (worksforme, doesn't work for me
etc.).
Could someone put something in the tracker to know what I am to
On 2020/03/12 09:22:09, dak wrote:
> On 2020/03/12 08:01:03, hahnjo wrote:
> > This looks like bash-ism which might explain why it works for
Han-Wen and me.
> I
> > agree with him that disabling the local-test invocation in
GNUmakefile.in is
> > probably the easiest solution for now. These tests ha
On 2020/03/12 08:01:03, hahnjo wrote:
> On 2020/03/11 23:49:23, dak wrote:
> > [...]
> > GNU LilyPond 2.21.0
> > cp: cannot stat '19.sub{-*.signature,.ly,-1.eps,.log,.profile}': No
such file
> or
> > directory
> > test results in ./out/test-output-distance
> > Traceback (most recent call last):
>
On 2020/03/11 23:49:23, dak wrote:
> [...]
> GNU LilyPond 2.21.0
> cp: cannot stat '19.sub{-*.signature,.ly,-1.eps,.log,.profile}': No
such file or
> directory
> test results in ./out/test-output-distance
> Traceback (most recent call last):
> File "/tmp/lilypond-autobuild/scripts/build/output-d
40 matches
Mail list logo
