Re: MacOS 64bit support

2019-12-15 Thread Werner LEMBERG


>>Sure! IIUC, I need to upload the patch to the code review tool and
>>update the issue tracker?  If so, could you (or someone else) give
>>my account yassinec write access to the issue tracker?  Otherwise I
>>can send the patch by email

Both is OK.

> I've added yassinec to the issue tracker with Create and Update
> permissions as well as Read. Welcome aboard!

Indeed :-)


Werner



A snippet for editing curves using the mouse and reporting changes to the .ly file

2019-12-15 Thread Paolo Prete
Hello,

the snippet attached to this mail allows the tuning with the mouse of the
curves generated by Lilypond so that the changes can be reflected on the
original .ly file.
The tuning is done on the generated SVG file, as explained in this thread
(but you can look at the code of the attached file, there's a mini how-to
and it's very simple to use):

https://lists.gnu.org/archive/html/lilypond-user/2019-12/msg00217.html

Since the snippet is incompatible with Lilypond 2.18 it cannot be included
in the snippets repository of that version, as explained by Thomas (it
would be bad to downgrade the code).
Is it possible to include it in the development version, then?

(I also ask Aaron to revise the indentation / length of lines of the Scheme
code)
The snippet has had very positive feedbacks, and should not be left without
a future, IMHO. I believe it can define a template for the tuning of many
other properties of graphic objects, in a very simple way both for the
Lilypond user and for those who want to extend the procedure through
Javascript.

In the Lilypond user ml they suggested to include it in Frescobaldi or
Denemo; but I don't think it's the best solution. Because, being the
snippet 100% lilypond native code, it does not need any additional tool to
work, and demonstrates the potential of Lilypond in generating interactive
SVG. To be more precise, given that it is 100% Lilypond, Frescobaldi and
Denemo should recognize it automatically.
It is also true, as Carl states, that LilyPond is not intended to be a
WYSIWYG software; but I believe that the "tuning" through GUI is not
opposed to this vision but integrates it, especially considering that the
GUI is generated by Lilypond itself.

Best,
Paolo
\version "2.19.45"

JSSVGSlurTuner = #(define-void-function (body) (string?)
   (let* ((mod (resolve-module '(scm framework-svg)))
  (svg-end (module-ref mod 'svg-end #f)))
 (if (procedure? svg-end)
   (module-define! mod 'svg-end (lambda () (string-join
 (list "" (svg-end)) "\n"))

JSSVGSlurTunerScript = #"
rootNode = document.querySelector('svg')
pixelsX  = rootNode.getAttribute('width').replace('mm', '') * 96 / 25.4
pixelsY  = rootNode.getAttribute('height').replace('mm', '') * 96 / 25.4
scaleX   = rootNode.getAttribute('viewBox').split(' ')[2] / pixelsX
scaleY   = rootNode.getAttribute('viewBox').split(' ')[3] / pixelsY

var slurId = 0
var currCp = null

function setCpsOnPath(path, x1, y1, x2, y2, x3, y3, x4, y4) {

	path.setAttribute('d', 'M ' + x1 + ',' + y1 + ' ' +
		'C ' + x2 + ',' + y2 + ' ' +
		x3 + ',' + y3 + ' ' +
		x4 + ',' + y4)

}

function initSlur(node) {

	//already initialized
	if (node.hasAttribute('id'))
		return

	cpsCounter = 1
	lineCounter = 1

	for (n1 = node.firstChild; n1 !== null; n1 = n1.nextSibling) {
		if (n1.nodeName == 'g') {
			for (n2 = n1.firstChild; n2 !== null; n2 = n2.nextSibling) {
			
if (n2.nodeName == 'circle') {
	if (!node.hasAttribute('cp' + cpsCounter + 'x')) {
		//TODO Ugly parsering, replace with a proper and safer one
		transf = n2.getAttribute('transform')
		node.setAttribute('cp' + cpsCounter + 'x',
			transf.replace('translate(', '').split(',')[0])
		node.setAttribute('cp' + cpsCounter + 'y',
			transf.split(',')[1].trim().replace(')', ''))
		n2.setAttribute('id', slurId + '_cp_' + cpsCounter)
		n2.setAttribute('onmousedown', 'selectCp(this)')
	}
	cpsCounter++
}

if (n2.nodeName == 'line') {
	n2.setAttribute('id', slurId + '_line_' + lineCounter)
	lineCounter++
}
			}
		}

		//remove 'transform' attribute and set abs coords
		if (n1.nodeName == 'path') {
			if (n1.hasAttribute('transform'))
n1.removeAttribute('transform')

			setCpsOnPath(n1,
   node.getAttribute('cp1x'),
   node.getAttribute('cp1y'),
   node.getAttribute('cp2x'),
   node.getAttribute('cp2y'),
   node.getAttribute('cp3x'),
   node.getAttribute('cp3y'),
   node.getAttribute('cp4x'),
   node.getAttribute('cp4y'))

			n1.setAttribute('id', slurId + '_path')
			n1.setAttribute('fill', 'none')
		}
	}

	node.setAttribute('id', slurId)

	coords = document.createElementNS('http://www.w3.org/2000/svg', 'text')
	coords.setAttribute('transform',
			'translate('+ node.getAttribute('cp1x') + ',' + 
		node.getAttribute('cp1y') + ')')
	coords.setAttribute('font-size', '2')
	coords.setAttribute('class', 'lilySlurCoords')
	coords.setAttribute('id', slurId + '_coords')
	node.appendChild(coords)

	slurId++

}

function selectCp(cp) {

	if (!cp.hasAttribute('id'))
		return

	if (!detectLeftButton(event)) {
		event.preventDefault()
		showCoords(cp.getAttribute('id').split('_')[0])
		return
	}

	cp.setAttribute('color', 'cyan')
	currCp = cp

}

function unselectCp() {

	if (currCp)
		

Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

2019-12-15 Thread dak

On 2019/12/15 14:40:08, dan_faithful.be wrote:

On Dec 15, 2019, at 06:31, mailto:lilyp...@de-wolff.org wrote:
> It is not the commit title, but I do think that this is not a part

of issue

5639: compile with --std=c11
> The reason that I think it is important to keep this separated is

that the

impact is very different.
> When a commit with only comments is in a separate issue, it is easy

to cherry

pick it for let say version 2.0.
> Although you make it a separate commit, in rietveld it is still one

issue.


The effort of handling a separate ticket and review is not worth it to

me for

this particular typo correction.  I'm willing to revert it and leave

it for the

next person who notices it, if that bothers you less than piggybacking

on this

issue.
—
Dan



Dan, a typo in a comment or in a doc string _not_ passed through Texinfo
or not containing Texinfo-relevant changes is material for just pushing
to staging in a commit of its own.  As you say, review is overkill, and
wrapping it into some other topic not touching a file is a distraction.

https://codereview.appspot.com/553310045/


Re[2]: MacOS 64bit support

2019-12-15 Thread Trevor




Yassine Chbani, you wrote 15/12/2019 20:49:32


Sure! IIUC, I need to upload the patch to the code review tool and update
the issue tracker? If so, could you (or someone else) give my account
yassinec write access to the issue tracker? Otherwise I can send the patch
by email
I've added yassinec to the issue tracker with Create and Update 
permissions

as well as Read. Welcome aboard!
Trevor


Re: MacOS 64bit support

2019-12-15 Thread Yassine Chbani
Sure! IIUC, I need to upload the patch to the code review tool and update
the issue tracker? If so, could you (or someone else) give my account
yassinec write access to the issue tracker? Otherwise I can send the patch
by email

On Sun, 15 Dec 2019 at 19:27, Werner LEMBERG  wrote:

>
> > Thanks for your answer, I managed to install Lilypond from macports,
> > it works like a charm.  We could include a note in the
> > website/documentation about this workaround, what do you think?
>
> Could you provide a patch to either the .html page or the
> corresponding .texi file?  (The latter might be difficult in case you
> are not acquainted with the texinfo input format.)
>
>
> Werner
>


Re: MacOS 64bit support

2019-12-15 Thread Werner LEMBERG


> Thanks for your answer, I managed to install Lilypond from macports,
> it works like a charm.  We could include a note in the
> website/documentation about this workaround, what do you think?

Could you provide a patch to either the .html page or the
corresponding .texi file?  (The latter might be difficult in case you
are not acquainted with the texinfo input format.)


Werner



Re: MacOS 64bit support

2019-12-15 Thread Yassine Chbani
Hello James,

Thanks for your answer, I managed to install Lilypond from macports, it
works like a charm. We could include a note in the website/documentation
about this workaround, what do you think?

Cheers,
Yassine

On Sun, 15 Dec 2019 at 16:19,  wrote:

> Hello Yassine,
>
> On 15/12/2019 15:08, Yassine Chbani wrote:
> > Hi all,
> >
> > Lilypond does not currently offer 64bit binaries for MacOS on its
> download
> > page . These
> 64bit
> > binaries are however necessary to run Lilypond on the latest macOS
> Catalina
> > release (that removed 32bit support).
> >
> > I am currently setting up GUB to try and compile Lilypond on the
> darwin-x86_64
> > platform, is there any particular issue I should be aware of regarding
> > 64bit compiling for MacOS targets?
>
> There has been a lot of discussion with regard to Mac OS about this on
> the developer lists.
>
> https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00272.html
> (Mac OS 64 bit generally)
>
> and
>
> https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00045.html
> (Gub Specific)
>
> and
>
> https://lists.gnu.org/archive/html/lilypond-devel/2019-02/msg00110.html
>
> If you have any comments/questions that are not answered here I suggest
> you ask/post in the developer lists than the bug lists.
>
> Regards
>
>
> James
>
>
>


input/regression/footnote-auto-numbering-vertical-order.ly is broken

2019-12-15 Thread Thomas Morley
Hi,

while working on #5640 "Fix regtests about Footnote"
https://sourceforge.net/p/testlilyissues/issues/5640/
I noticed input/regression/footnote-auto-numbering-vertical-order.ly is broken.

The problem is that since #1773 "Add Footnote_engraver to Score context"
https://sourceforge.net/p/testlilyissues/issues/1773/
\override FootnoteItem.numbering-assertion-function always fails now,
if correctly applied to Score _and_ more than one FootnoteItem happen
at the same time, p.e.in simultaneous music.

Short example:

#(define (make-footnote-numbering-assertion-function n)
  (lambda (x)
(if (not (= n x))
  (ly:warning (_ "Expecting number ~a, got ~a") n x

#(set-default-paper-size "a6")

<<
  \new Staff
{
\once \override Score.FootnoteItem.numbering-assertion-function =
  #(lambda (grob) (make-footnote-numbering-assertion-function 0))
\footnote #'(1 . -1) "1. footnote" b
}
  \new Staff
{
\once \override Score.FootnoteItem.numbering-assertion-function =
  #(lambda (grob) (make-footnote-numbering-assertion-function 1))
\footnote #'(1 . -1) "2. footnote" b
}
>>

The numbering-assertion-function receives two values 0 and 1. Thus it
can't assert any fix value anymore.
Currently I can't find a way out.
Suggestions/hints?

Background:
numbering-assertion-function was implemented with

commit 5ac2664c2207e8dfa1734d786e5c7b214b275521
Author: Mike Solomon 
Date:   Fri Dec 2 08:06:13 2011 +0100

Adds a numbering-assertion-function property to the footnote grob.

This allows the footnote regtests to verify that the footnotes are
being numbered in the correct order.

for 2.15.21

Moving Footnote_engraver with:
commit 3f0f59297670174562e7d66ae7dd8d73a04be6f8
Author: David Kastrup 
Date:   Fri May 25 18:41:46 2012 +0200

Issue 1773: move Footnote_engraver to Score context

for 2.15.40

The problem remained undetected because the
numbering-assertion-function was not called with Score-context, so it
didn't work at all.
The regtest does not rely on a visual diff, but on a triggered
ly:error, which then never happened anymore.

The regtest footnote-auto-numbering.ly uses
numbering-assertion-function as well, but without simultaneous
Footnotes, thus it works there.


Cheers,
  Harm



Re: Fix regtests about Footnote (issue 549320043 by thomasmorle...@gmail.com)

2019-12-15 Thread thomasmorley65

patch-description is changed.
Fixing footnote-auto-numbering-vertical-order.ly will take more work
than simply correct context-settings

https://codereview.appspot.com/549320043/



Re: MacOS 64bit support

2019-12-15 Thread pkx166h

Hello Yassine,

On 15/12/2019 15:08, Yassine Chbani wrote:

Hi all,

Lilypond does not currently offer 64bit binaries for MacOS on its download
page . These 64bit
binaries are however necessary to run Lilypond on the latest macOS Catalina
release (that removed 32bit support).

I am currently setting up GUB to try and compile Lilypond on the darwin-x86_64
platform, is there any particular issue I should be aware of regarding
64bit compiling for MacOS targets?


There has been a lot of discussion with regard to Mac OS about this on 
the developer lists.


https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00272.html 
(Mac OS 64 bit generally)


and

https://lists.gnu.org/archive/html/lilypond-devel/2019-10/msg00045.html 
(Gub Specific)


and

https://lists.gnu.org/archive/html/lilypond-devel/2019-02/msg00110.html

If you have any comments/questions that are not answered here I suggest 
you ask/post in the developer lists than the bug lists.


Regards


James





Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

2019-12-15 Thread Dan Eble
On Dec 15, 2019, at 06:31, lilyp...@de-wolff.org wrote:
> It is not the commit title, but I do think that this is not a part of issue 
> 5639: compile with --std=c11
> The reason that I think it is important to keep this separated is that the 
> impact is very different.
> When a commit with only comments is in a separate issue, it is easy to cherry 
> pick it for let say version 2.0.
> Although you make it a separate commit, in rietveld it is still one issue.

The effort of handling a separate ticket and review is not worth it to me for 
this particular typo correction.  I'm willing to revert it and leave it for the 
next person who notices it, if that bothers you less than piggybacking on this 
issue.
— 
Dan




RE: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

2019-12-15 Thread lilypond
> -Original Message-
> From: nine.fierce.ball...@gmail.com 
> Sent: Saturday, December 14, 2019 8:52 PM
> To: lemzw...@googlemail.com; jonas.hahnf...@gmail.com; d...@gnu.org;
> haber...@telia.com; lilyp...@de-wolff.org
> Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com
> Subject: Re: Issue 5639: compile with -std=c++11 (issue 553310045 by
> nine.fierce.ball...@gmail.com)
> 
> On 2019/12/14 18:23:08, lilypond_de-wolff.org wrote:
> > Great job, one remark:
> > Although the patch for ly/music-functions-init.ly is a good patch, I
> do not
> > think it should be part of this patch-set.
> 
> > Jaap
> 
> 
> It's part of the commit titled "comments."  What do you suggest I do instead?
> 
> 
> https://codereview.appspot.com/553310045/
[>] 

It is not the commit title, but I do think that this is not a part of issue 
5639: compile with --std=c11
The reason that I think it is important to keep this separated is that the 
impact is very different.
When a commit with only comments is in a separate issue, it is easy to cherry 
pick it for let say version 2.0.
Although you make it a separate commit, in rietveld it is still one issue.

Jaap





PATCHES - Countdown for December 15th

2019-12-15 Thread pkx166h

Hello,

Here is the current patch countdown list. The next countdown will be on 
December 17th.


A quick synopsis of all patches currently in the review process can be 
found here:


http://philholmes.net/lilypond/allura/




 Push:

5634 aclocal.m4: Avoid usage of Python - Jonas Hahnfeld 
https://sourceforge.net/p/testlilyissues/issues/5634 
http://codereview.appspot.com/583180043


5633 musicxml: Replace new module by type() builtin - Jonas Hahnfeld 
https://sourceforge.net/p/testlilyissues/issues/5633 
http://codereview.appspot.com/555070043


5632 Replace string exceptions by RuntimeError - Jonas Hahnfeld 
https://sourceforge.net/p/testlilyissues/issues/5632 
http://codereview.appspot.com/549270043



 Countdown:

5637 Port lilysong to subprocess module - Jonas Hahnfeld 
https://sourceforge.net/p/testlilyissues/issues/5637 
http://codereview.appspot.com/561240043


5636 fix various warnings - Dan Eble 
https://sourceforge.net/p/testlilyissues/issues/5636 
http://codereview.appspot.com/583200043


5635 show new regression-test cases - Dan Eble 
https://sourceforge.net/p/testlilyissues/issues/5635 
http://codereview.appspot.com/577190043


5310 find_top_context () instead of get_global_context () - Dan Eble 
https://sourceforge.net/p/testlilyissues/issues/5310 
http://codereview.appspot.com/565320043



 Review:

5641 Drop undocumented lilymidi and lilysong - Jonas Hahnfeld 
https://sourceforge.net/p/testlilyissues/issues/5641 
http://codereview.appspot.com/571250043


5639 compile with -std=c++11 - Dan Eble 
https://sourceforge.net/p/testlilyissues/issues/5639 
http://codereview.appspot.com/553310045


5631 Introduce breakingRehearsalMarks for line-breaking RehearsalMarks - 
Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5631 
http://codereview.appspot.com/577180043



 New:

5621 Improve positioning of rehearsal marks at the beginning of staff - 
Werner LEMBERG https://sourceforge.net/p/testlilyissues/issues/5621 
http://codereview.appspot.com/553290043



***


Regards,

James