Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Simon Albrecht

On 22.12.2016 02:17, Thomas Morley wrote:

2016-12-22 1:33 GMT+01:00 Knut Petersen:

Hi everybody!

Attached find a new version of the patch.
Please test. Read the updated manuals.

Feel free to provide corrections and translations!

cu,
  Knut


Hi Knut,

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process now. 
Knut, are you familiar with the git cl proceedings? If not, it’s 
explained in the CG 1.3 and 2.3.


Best, Simon

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Trevor Daniels

Knut Petersen wrote Thursday, December 22, 2016 12:33 AM

> Attached find a new version of the patch.
> Please test. Read the updated manuals.
> 
> Feel free to provide corrections and translations!

Looks promising.  I have several comments to make, but it will be
much easier to do that when the patch has reached Review stage
on Rietveld.

Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: linux-ppc harfbuzz GUB build error

2016-12-22 Thread Masamichi Hosoda
 In my environments, autoconf does not raise such error.
 Do you set the "set -u" or "set -o nounset" somewhere?
 If so, would you remove the setting?
>>> The set -u (or to be complete set -ux) I discovered inside
>>> 
>>> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh
>>> 
>>> which was the command that was called when the error was signalled
>> 
>> I've noticed that smart-autogen.sh has "set -ux" and it is invoked from GUB.
>> If I understand correctly, "set -u" and "set -x" etc. do not carry over
>> into child processes.
>> 
>> However, at least in your log file,
>> "set -x" seems to be carried over to the child process.
>> From smart-autogen.sh through autogen.sh to autoconf,
>> all scripts are setted trace mode.
>> 
> [...snip...]
>> 
>> Perhaps, also "set -u" is carried over in your environment
>> and it is not carried over in my environment.
>> 
>> I have no idea.
>> But, in CentOS, /bin/sh is symbolic link to bash,
>> whereas in Ubuntu, /bin/sh is dash.
>> I think that this difference is influenced.
> 
> Anyway, I've noticed that if the environment variable SHELLOPTS exists,
> "set -ux" and "set -e" carry over to the child processes.
> There may be other conditions that it carries over.
> 
> In order to avoid this issue,
> there is a way to "set +ux" before invoking the child process.
> So I've created a patch for LilyPond's smart-autogen.sh and 
> smart-configure.sh.
> 
> https://sourceforge.net/p/testlilyissues/issues/5013/
> https://codereview.appspot.com/319870043/

It has been merged.
Probably the issue on CentOS has been solved.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Alexander Kobel

On 2016-12-22 13:03, Simon Albrecht wrote:

On 22.12.2016 02:17, Thomas Morley wrote:

2016-12-22 1:33 GMT+01:00 Knut Petersen:

Hi everybody!

Attached find a new version of the patch.
Please test. Read the updated manuals.

Feel free to provide corrections and translations!

cu,
  Knut


Hi Knut,

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process now.
Knut, are you familiar with the git cl proceedings? If not, it’s
explained in the CG 1.3 and 2.3.


+1. Let us know if you need help. I went through the procedure just a 
few days ago, so my knowledge is scarce, but fresh.


That being said, I have a question left: is it possible to automatically 
checkout a Rietveld patch set to a new branch (via git and/or git-cl), 
or does one have to manually download and apply the patch set?



Cheers,
Alexander

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: music function to be included somewhere in scm/*

2016-12-22 Thread Alexander Kobel

On 2016-12-21 17:05, tisimst wrote:

On Wed, Dec 21, 2016 at 5:22 AM, Alexander Kobel-2 [via Lilypond] <
ml-node+s1069038n198284...@n5.nabble.com> wrote:

On 2016-12-20 17:21, Abraham Lee wrote:

Maybe the question I really have is this: what does "given this
length _if possible_" mean and what governs this possibility? I
can totally understand how they work individually, I'm just
trying to understand how I can use them well together since it
seems that forced-length contradicts collapse-length.


You won't really use them together; at least, not both will be effective
at the same time:
(1) If the natural length (essentially: the distance from the right end
of the syllable to the right end of the last note in the corresponding
melisma) is less than collapse-length, this extender will not be printed.
(2) If you /force/ an extender, that is, you explicitly add one for a
syllable that does not belong to a melisma, there is no "natural length"
- simply because there is no "natural extender". The "faked" length of
such an extender will be given by the minimum of forced-length and the
available space to the next syllable. Again, this will not affect the
space between the notes.

Forced extenders should only be necessary under extraordinary
circumstances, such as an extender reaching into a alternative ending of
a repeat, re-extending after rests, or even more obscure design studies.


Ah! I understand now. Thank you for explaining that. So, it's "Force an
extender to appear if there is sufficient space (i.e., at least as much as
"collapse-length"), even in places they wouldn't normally be used."


No, it's just "force an extender to appear even in places they wouldn't 
normally be used".



Is that right? If so, then I think "forced-length" is not the right name for it.
Perhaps just "force" or "force-all"? Or is forced appearance not subject to
"collapse-length"?


The latter. It is well possible (and reasonable, given that you need 
forced extenders at all) to set collapse-length > forced-length. You 
explicitly ask for an extender to be printed, so you would not want it 
to be collapsed again.



Cheers,
Alexander

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Knut Petersen

Hi Alexander et al.!

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process now.
Knut, are you familiar with the git cl proceedings? If not, it’s
explained in the CG 1.3 and 2.3.


+1. Let us know if you need help. I went through the procedure just a few days ago, so my knowledge is scarce, but fresh. 


As I will not do it anybody is invited to put that patch on Rietveld. You might 
call me pigheaded,
but I don't accept to be forced to use a google account. Of course I will react 
to any reasonable
change request.

Cheers,
 Knut

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Knut Petersen

Hi Werner!


One nit: Please avoid overlong lines in the source code; it should be
limited to 80 characters per line to improve legibility.



Well, a number of lines are longer than 80 characters, but most are shorter than
their predecessors. If the 80 character limit should be obeyed, it would be no
problem to reformat e.g. lyric-extender.cc.

Cheers,
 Knut



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Urs Liska
Am 22.12.2016 um 15:00 schrieb Knut Petersen:
> Hi Werner!
> 
>> One nit: Please avoid overlong lines in the source code; it should be
>> limited to 80 characters per line to improve legibility.
>>
> 
> Well, a number of lines are longer than 80 characters, but most are
> shorter than
> their predecessors. If the 80 character limit should be obeyed, it would
> be no
> problem to reformat e.g. lyric-extender.cc.

The Rietveld diff viewer produces really ugly line breaks strictly from
character 81 on, so that's a reasonable request.

Urs

> 
> Cheers,
>  Knut
> 
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel


-- 
Urs Liska
www.openlilylib.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Alexander Kobel

On 2016-12-22 14:53, Knut Petersen wrote:

Hi Alexander et al.!

how about putting the patch on Rietveld?


I agree that this should go into a normal patch review process
now. Knut, are you familiar with the git cl proceedings? If not,
it’s explained in the CG 1.3 and 2.3.


+1. Let us know if you need help. I went through the procedure just
a few days ago, so my knowledge is scarce, but fresh.


As I will not do it anybody is invited to put that patch on
Rietveld. You might call me pigheaded, but I don't accept to be
forced to use a google account. Of course I will react to any
reasonable change request.


I get your point. I dislike it as well, but gave in to the pressure (not 
here, but elsewhere) long ago. I try to keep contact data and calendar 
away from the big G as much as possible, and only use the mail address 
to forward to another, but still. Go{d,ogle} alone knows what they 
harvest...


Anyway, I can take care of uploading the patch. Will do so in the 
evening, most probably.



Cheers,
Alexander

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: linux-ppc harfbuzz GUB build error

2016-12-22 Thread Hans Aikema

> On 22 Dec 2016, at 14:05, Masamichi Hosoda  wrote:
> 
> In my environments, autoconf does not raise such error.
> Do you set the "set -u" or "set -o nounset" somewhere?
> If so, would you remove the setting?
 The set -u (or to be complete set -ux) I discovered inside
 
 /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh
 
 which was the command that was called when the error was signalled
>>> 
>>> I've noticed that smart-autogen.sh has "set -ux" and it is invoked from GUB.
>>> If I understand correctly, "set -u" and "set -x" etc. do not carry over
>>> into child processes.
>>> 
>>> However, at least in your log file,
>>> "set -x" seems to be carried over to the child process.
>>> From smart-autogen.sh through autogen.sh to autoconf,
>>> all scripts are setted trace mode.
>>> 
>> [...snip...]
>>> 
>>> Perhaps, also "set -u" is carried over in your environment
>>> and it is not carried over in my environment.
>>> 
>>> I have no idea.
>>> But, in CentOS, /bin/sh is symbolic link to bash,
>>> whereas in Ubuntu, /bin/sh is dash.
>>> I think that this difference is influenced.
>> 
>> Anyway, I've noticed that if the environment variable SHELLOPTS exists,
>> "set -ux" and "set -e" carry over to the child processes.
>> There may be other conditions that it carries over.
>> 
>> In order to avoid this issue,
>> there is a way to "set +ux" before invoking the child process.
>> So I've created a patch for LilyPond's smart-autogen.sh and 
>> smart-configure.sh.
>> 
>> https://sourceforge.net/p/testlilyissues/issues/5013/
>> https://codereview.appspot.com/319870043/
> 
> It has been merged.
> Probably the issue on CentOS has been solved.

Retrying a CentOS build alongside trial-and-error builds with minimal Ubuntu 
environment
My current minimal ubuntu-based build is running the base dockerized 
ubuntu:xenial image extended with
g++-multilib  \
git  \
ca-certificates  \
zip  \
unzip  \
make  \
python  \
file  \
xz-utils  \
gettext  \
curl  \
p7zip-full  \
texlive-xetex \

might still need more packages before it’s up and running

The ubuntu minimal environment builds alread led to a couple of updates in my 
gub fork (https://github.com/aikebah/gub) for URLs that are wget-able, but not 
curl-able as curl is not following the http 301 moved permanently redirects (at 
least python.org and freedesktop.org …. new minimal ubuntu build running to see 
if more packages fail the bootstrap when only curl is available.

once I pass the gub bootstrap I’ll create a pull-request for the URL updates


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Doc CG 6.1: Add caveat on website work (issue 315130043 by gra...@percival-music.ca)

2016-12-22 Thread Federico Bruni
Il giorno mer 7 dic 2016 alle 8:01, Graham Percival 
 ha scritto:

On Mon, Dec 05, 2016 at 06:03:28PM +, Carl Sorensen wrote:


 On 12/5/16 10:28 AM, "lilypond-devel on behalf of Graham Percival"
  wrote:

 >The website *is* tied to the documentation.  That decision was
 >made in 2009, and the reasons are just as valid today.


What does it mean? That website and documentation must be generated 
with the same tool?

Which are the valid reasons for this?



 I believe you when you say this.  But I am having a hard time 
finding a

 record of the decision.  I expected to find it in the CG under
 Administrative Policies or under Website work.  I couldn't find it 
either

 place.  Can you help me find a pointer to the discussion and/or the
 decision rationale?


Good question, and I still don't have a good answer.  This was
before we started keeping records of any decisions.  The earliest
I found was this:
http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00574.html
which didn't spark a whole lot of discussion.  The current website
didn't start to become visible until late 2009.


Well, I cannot help quoting Reinhold enthusiasm about working on 
texi2html:


 Phew, thank god you are not asking me to write another .init file for
 texi2html! I don't have many hairs left, so pulling out my hair is no 
option

 ;-)

from:
http://lists.gnu.org/archive/html/lilypond-devel/2008-12/msg00596.html

You can imagine the enthusiasm of those coming afterwards...



I had a vague memory of a much more in-depth discussion, but
perhaps that was sometime in 2010 or 2011.  I'll continue to trawl
through the archives to see if there's more info.



I don't think that links to previous discussions are _so_ important.
I'd be curious to know the valid reasons.




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: LilyDev 5.0 released

2016-12-22 Thread Paul

Hi Federico,

Thanks and congrats on the new release!

I gave it a try.  Installation seemed to go fine, but then on booting it 
up I get past the GRUB screen and then it goes to a black unresponsive 
screen at "loading initial ramdisk..."  Haven't had a chance to 
troubleshoot it further.  I'm attaching the log file in case anyone 
wants to take a look.


(I'm on Ubuntu 16.04 and Virtual Box version 5.0.24_Ubuntu r108355)  
(I'm using LilyDev on Ubuntu because I'm new to GNU/Linux and already 
familiar with LilyDev.)


Cheers,
-Paul


VirtualBox VM 5.0.24_Ubuntu r108355 linux.amd64 (Jul  5 2016 08:17:21) release log
00:00:00.255348 Log opened 2016-12-22T17:42:07.876411000Z
00:00:00.255350 Build Type: release
00:00:00.255352 OS Product: Linux
00:00:00.255353 OS Release: 4.4.0-57-generic
00:00:00.255354 OS Version: #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016
00:00:00.255369 DMI Product Name: 20AQ005QUS
00:00:00.255373 DMI Product Version: ThinkPad T440s
00:00:00.255405 Host RAM: 7673MB total, 4419MB available
00:00:00.255408 Executable: /usr/lib/virtualbox/VirtualBox
00:00:00.255408 Process ID: 4534
00:00:00.255409 Package type: LINUX_64BITS_GENERIC (OSE)
00:00:00.259714 Installed Extension Packs:
00:00:00.259731   VNC (Version: 5.0.24 r108355; VRDE Module: VBoxVNC)
00:00:00.260408 Console: Machine state changed to 'Starting'
00:00:00.264780 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:00:00.265173 Using XKB for keycode to scan code conversion
00:00:00.267600 SUP: Loaded VMMR0.r0 (/usr/lib/virtualbox/VMMR0.r0) at 0xc0b06020 - ModuleInit at c0b26d70 and ModuleTerm at c0b27260
00:00:00.267630 SUP: VMMR0EntryEx located at c0b2a940 and VMMR0EntryFast at c0b29fb0
00:00:00.295495 Guest OS type: 'Debian'
00:00:00.339378 File system of '/home/paul/VirtualBox VMs/LilyDev5Box/Snapshots' (snapshots) is unknown
00:00:00.339391 File system of '/home/paul/VirtualBox VMs/LilyDev5Box/LilyDev5Box.vdi' is ext4
00:00:00.355544 Shared clipboard service loaded
00:00:00.33 Shared clipboard mode: Off
00:00:00.356381 Drag and drop service loaded
00:00:00.356390 Drag and drop mode: Off
00:00:00.358443 Guest Control service loaded
00:00:00.359993 * CFGM dump *
00:00:00.360001 [/] (level 0)
00:00:00.360017   CSAMEnabled= 0x0001 (1)
00:00:00.360023   CpuExecutionCap= 0x0064 (100)
00:00:00.360025   EnablePAE  = 0x0001 (1)
00:00:00.360027   HMEnabled  = 0x0001 (1)
00:00:00.360029   MemBalloonSize = 0x (0)
00:00:00.360030   Name= "LilyDev5Box" (cb=12)
00:00:00.360033   NumCPUs= 0x0001 (1)
00:00:00.360034   PATMEnabled= 0x0001 (1)
00:00:00.360036   PageFusionAllowed  = 0x (0)
00:00:00.360038   RamHoleSize= 0x2000 (536 870 912, 512 MB)
00:00:00.360040   RamSize= 0xbdb0 (3 182 428 160, 2 GB)
00:00:00.360043   RawR0Enabled   = 0x0001 (1)
00:00:00.360044   RawR3Enabled   = 0x0001 (1)
00:00:00.360046   TimerMillies   = 0x000a (10)
00:00:00.360048   UUID = "de 48 55 bd 25 37 cf 4a b4 15 ca 1f 6f 40 c8 6f" (cb=16)
00:00:00.360054 
00:00:00.360057 [/CPUM/] (level 1)
00:00:00.360060   PortableCpuIdLevel  = 0x (0)
00:00:00.360061 
00:00:00.360066 [/DBGF/] (level 1)
00:00:00.360068   Path   = "/home/paul/VirtualBox VMs/LilyDev5Box/debug/;/home/paul/VirtualBox VMs/LilyDev5Box/;/home/paul/" (cb=96)
00:00:00.360070 
00:00:00.360070 [/Devices/] (level 1)
00:00:00.360072 
00:00:00.360072 [/Devices/8237A/] (level 2)
00:00:00.360074 
00:00:00.360075 [/Devices/8237A/0/] (level 3)
00:00:00.360077   Trusted  = 0x0001 (1)
00:00:00.360078 
00:00:00.360079 [/Devices/GIMDev/] (level 2)
00:00:00.360080 
00:00:00.360081 [/Devices/GIMDev/0/] (level 3)
00:00:00.360083   Trusted  = 0x0001 (1)
00:00:00.360084 
00:00:00.360085 [/Devices/VMMDev/] (level 2)
00:00:00.360086 
00:00:00.360087 [/Devices/VMMDev/0/] (level 3)
00:00:00.360089   PCIBusNo   = 0x (0)
00:00:00.360090   PCIDeviceNo= 0x0004 (4)
00:00:00.360091   PCIFunctionNo  = 0x (0)
00:00:00.360093   Trusted= 0x0001 (1)
00:00:00.360094 
00:00:00.360095 [/Devices/VMMDev/0/Config/] (level 4)
00:00:00.360097   GuestCoreDumpDir   = "/home/paul/VirtualBox VMs/LilyDev5Box/Snapshots" (cb=48)
00:00:00.360098   RamSize   = 0xbdb0 (3 182 428 160, 2 GB)
00:00:00.360100 
00:00:00.360101 [/Devices/VMMDev/0/LUN#0/] (level 4)
00:00:00.360103   Driver   = "HGCM" (cb=5)
00:00:00.360104 
00:00:00.360105 [/Devices/VMMDev/0/LUN#0/Config/] (level 5)
00:00:00.360107   Object  = 0x7fbb6c000910 (140 442 947 553 552)
00:00:00.360109 
00:00:00.360109 [/Devices/VMMDev/0/LUN#999/] (level 4)
00:00:00.360111   Driver   = "MainStatus" 

Re: linux-ppc harfbuzz GUB build error

2016-12-22 Thread Hans Aikema

> On 22 Dec 2016, at 18:20, Hans Aikema  wrote:
> 
> 
>> On 22 Dec 2016, at 14:05, Masamichi Hosoda  wrote:
>> 
>> In my environments, autoconf does not raise such error.
>> Do you set the "set -u" or "set -o nounset" somewhere?
>> If so, would you remove the setting?
> The set -u (or to be complete set -ux) I discovered inside
> 
> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh
> 
> which was the command that was called when the error was signalled
 
 I've noticed that smart-autogen.sh has "set -ux" and it is invoked from 
 GUB.
 If I understand correctly, "set -u" and "set -x" etc. do not carry over
 into child processes.
 
 However, at least in your log file,
 "set -x" seems to be carried over to the child process.
 From smart-autogen.sh through autogen.sh to autoconf,
 all scripts are setted trace mode.
 
>>> [...snip...]
 
 Perhaps, also "set -u" is carried over in your environment
 and it is not carried over in my environment.
 
 I have no idea.
 But, in CentOS, /bin/sh is symbolic link to bash,
 whereas in Ubuntu, /bin/sh is dash.
 I think that this difference is influenced.
>>> 
>>> Anyway, I've noticed that if the environment variable SHELLOPTS exists,
>>> "set -ux" and "set -e" carry over to the child processes.
>>> There may be other conditions that it carries over.
>>> 
>>> In order to avoid this issue,
>>> there is a way to "set +ux" before invoking the child process.
>>> So I've created a patch for LilyPond's smart-autogen.sh and 
>>> smart-configure.sh.
>>> 
>>> https://sourceforge.net/p/testlilyissues/issues/5013/
>>> https://codereview.appspot.com/319870043/
>> 
>> It has been merged.
>> Probably the issue on CentOS has been solved.
> 
> Retrying a CentOS build alongside trial-and-error builds with minimal Ubuntu 
> environment
> My current minimal ubuntu-based build is running the base dockerized 
> ubuntu:xenial image extended with
>g++-multilib  \
>git  \
>ca-certificates  \
>zip  \
>unzip  \
>make  \
>python  \
>file  \
>xz-utils  \
>gettext  \
>curl  \
>p7zip-full  \
>texlive-xetex \
> 
> might still need more packages before it’s up and running
> 
> The ubuntu minimal environment builds alread led to a couple of updates in my 
> gub fork (https://github.com/aikebah/gub) for URLs that are wget-able, but 
> not curl-able as curl is not following the http 301 moved permanently 
> redirects (at least python.org and freedesktop.org …. new minimal ubuntu 
> build running to see if more packages fail the bootstrap when only curl is 
> available.
> 
> once I pass the gub bootstrap I’ll create a pull-request for the URL updates
> 
Note: my assumption was that it is a curl vs wget availability issue that 
caused my HTTPError() on download, but upon further inspection it seems a 
python library that is used for the downloads…. no clue yet why on my system it 
failes for HTTP 301-ed URL, whereas it apparently works fine for others. Could 
this be related to python-version of the host on which gub is running?




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: LilyDev 5.0 released

2016-12-22 Thread James

Hello Paul


On 22/12/16 17:48, Paul wrote:

Hi Federico,

Thanks and congrats on the new release!

I gave it a try.  Installation seemed to go fine, but then on booting 
it up I get past the GRUB screen and then it goes to a black 
unresponsive screen at "loading initial ramdisk..."  Haven't had a 
chance to troubleshoot it further.  I'm attaching the log file in case 
anyone wants to take a look.


(I'm on Ubuntu 16.04 and Virtual Box version 5.0.24_Ubuntu r108355)  
(I'm using LilyDev on Ubuntu because I'm new to GNU/Linux and already 
familiar with LilyDev.)


Cheers,
-Paul



I also tried to install LilyDev 5.0 last week - I use Ubuntu 16.0.4 with 
the latest 64 bit vBox 5.1.x test build (112223 w Ext pack 112433).


https://www.virtualbox.org/wiki/Testbuilds

(I have been using it for the last week or so without any problems for 
my 'work' VM it's very stable and fixed some annoying clipboard issues I 
was having with the one in the repos).


If you want to give it a go in case it is the repo version that is at 
fault - which is a bit behind the current stable release even.


1. Uninstall the vBox package from the Software Repo (I assume you 
apt-get installed it? So apt-get remove it).


2. Download the 'Linux 64 bit' version of the 5.1.x build. with the 
Extension Pack.


3. You will need to chmod +x the Installer.

4. Then run the exe as root (sudo ./VirtualBox_5...) and it will install 
all the bits and bobs for you.


5. Start the Virtual Box UI and then apply the extension pack via the 
'files/preferences -> Extensions' part of the UI.


I don't use any special settings other than 3 or 4 CPUs, disable sound 
and enable PAE for my Hardware.



I have not had the same problems as your self and it boots very quick.

I know that doesn't help you diagnose your issue, but as a second point 
of reference, albeit with a newer version of Virtual Box it seems to 
work for me.


James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: [PATCH] Automatic lyric extenders

2016-12-22 Thread Werner LEMBERG

>> One nit: Please avoid overlong lines in the source code; it should
>> be limited to 80 characters per line to improve legibility.
> 
> Well, a number of lines are longer than 80 characters, but most are
> shorter than their predecessors.  If the 80 character limit should
> be obeyed, it would be no problem to reformat e.g.
> lyric-extender.cc.

Complete formatting of source code files should be avoided, since it
makes it hard to compare them with older versions of the files.
However, proper formatting of new or changed source code lines should
be preferred.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Two small amendments to Doc/web/community.itexi (issue 319880043 by simon.albre...@mail.de)

2016-12-22 Thread graham


https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):

https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi#newcode434
Documentation/web/community.itexi:434: every bug can be demonstrated in
four lines of code or less!}
Hmm, I think "four notes" is shorter (and easier to understand) than
"four lines of codes".  I mean, people can stuff a lot of extra material
into four lines of code!

The place that discusses "four lines of code" in Tiny examples is at the
bottom of a longer explanation about the process.  As such, I think it
serves a different purpose.  The main point of this @warning{} is to get
people to look at "Tiny examples".

https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi#newcode498
Documentation/web/community.itexi:498: any activity on the bug occurs.
For that, just click the envelope
I would replace ".  For that, just click" with "by clicking".  So that
area would be:

... any activity on the bug occurs, by clicking the envelope symbol...

https://codereview.appspot.com/319880043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Point to \resetRelativeOctave in NR 1.1.1.b (issue 312210043 by simon.albre...@mail.de)

2016-12-22 Thread graham

LGTM

https://codereview.appspot.com/312210043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Doc: remove www from lilypond.org URL (issue 312190043 by fedel...@gmail.com)

2016-12-22 Thread graham

LGTM, and I'm happy with pushing it directly to staging.

https://codereview.appspot.com/312190043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: add choral and choral-cautionary accidental style (issue 311430043 by perpeduumimmob...@gmail.com)

2016-12-22 Thread graham

LGTM

https://codereview.appspot.com/311430043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Two small amendments to Doc/web/community.itexi (issue 319880043 by simon.albre...@mail.de)

2016-12-22 Thread Simon Albrecht

On 22.12.2016 23:21, gra...@percival-music.ca wrote:


https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi 


File Documentation/web/community.itexi (right):

https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi#newcode434 


Documentation/web/community.itexi:434: every bug can be demonstrated in
four lines of code or less!}
Hmm, I think "four notes" is shorter (and easier to understand) than
"four lines of codes".


All right, change reverted.



https://codereview.appspot.com/319880043/diff/1/Documentation/web/community.itexi#newcode498 


Documentation/web/community.itexi:498: any activity on the bug occurs.
For that, just click the envelope
I would replace ".  For that, just click" with "by clicking".  So that
area would be:

... any activity on the bug occurs, by clicking the envelope symbol...


I didn’t want to separate the ‘by clicking’ so much from the ‘subscribe’ 
to which it refers,

so I chose yet another wording I hope you’ll agree to.

Best, Simon

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Two small amendments to Doc/web/community.itexi (issue 319880043 by simon.albre...@mail.de)

2016-12-22 Thread graham

LGTM

https://codereview.appspot.com/319880043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: LilyDev 5.0 released

2016-12-22 Thread Federico Bruni
Il giorno gio 22 dic 2016 alle 18:48, Paul  ha 
scritto:
I gave it a try.  Installation seemed to go fine, but then on booting 
it up I get past the GRUB screen and then it goes to a black 
unresponsive screen at "loading initial ramdisk..."  Haven't had a 
chance to troubleshoot it further.  I'm attaching the log file in 
case anyone wants to take a look.


(I'm on Ubuntu 16.04 and Virtual Box version 5.0.24_Ubuntu r108355)  
(I'm using LilyDev on Ubuntu because I'm new to GNU/Linux and already 
familiar with LilyDev.)


Hi Paul

In the log I see this line:

00:00:00.447635   PAE - Physical Address Extension  
 = 0 (0)


which makes me think that you've not enabled PAE?
There's a warning in the CG about this:

The image contains a ‘686-pae’ kernel, so you must enable PAE 
within the virtual machine’s settings – click on System → 
Processor and select ‘Extended features: Enable PAE/NX’.


http://lilypond.org/doc/v2.19/Documentation/contributor/lilydev#installing-lilydev-in-virtualbox

I remember that Virtual Box used to shout if PAE was not enabled. But 
the last time I checked it was some time ago.


Let me know if this helps.
Otherwise I may suggest another virtualization system, libvirt, that I 
use and know better than Virtual Box.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel