Re: LilyDev not accepting paste from host clipboard
On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote: Thanks Richard, I never used it and I ignored its existence. I'll add that directory to the path in .bashrc. In light of the further steps it isn't useful to add that directory to the PATH (because the command will not work unless the it is the cwd). It is just the web page instructions that need updating to read cd $LILYPOND_GIT lily-git.tcl rather than Type (or copypaste) into the Terminal: lily-git.tcl as at present. It's not worth a new iso update IMO. right - the iso seems to be working just fine - with guest extensions working out of the box (and that cyrillic thing too). BTW my first make failed in the docs - is that expected? Richard ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond.org is down (as of 08:12 UTC)
http://www.downforeveryoneorjustme.com/lilypond.org James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev not accepting paste from host clipboard
On 21/09/14 08:55, Richard Shann wrote: On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote: Thanks Richard, I never used it and I ignored its existence. I'll add that directory to the path in .bashrc. In light of the further steps it isn't useful to add that directory to the PATH (because the command will not work unless the it is the cwd). It is just the web page instructions that need updating to read cd $LILYPOND_GIT lily-git.tcl rather than Type (or copypaste) into the Terminal: lily-git.tcl as at present. It's not worth a new iso update IMO. right - the iso seems to be working just fine - with guest extensions working out of the box (and that cyrillic thing too). BTW my first make failed in the docs - is that expected? Richard No. What did it fail with? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev not accepting paste from host clipboard
On 21/09/14 08:55, Richard Shann wrote: On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote: Thanks Richard, I never used it and I ignored its existence. I'll add that directory to the path in .bashrc. In light of the further steps it isn't useful to add that directory to the PATH (because the command will not work unless the it is the cwd). It is just the web page instructions that need updating to read cd $LILYPOND_GIT lily-git.tcl rather than Type (or copypaste) into the Terminal: lily-git.tcl as at present. It's not worth a new iso update IMO. right - the iso seems to be working just fine - with guest extensions working out of the box (and that cyrillic thing too). BTW my first make failed in the docs - is that expected? Richard Just to check you did a 'make' before you 'make doc' didn't you? It will fail then otherwise. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev not accepting paste from host clipboard
On Sun, 2014-09-21 at 09:14 +0100, James wrote: On 21/09/14 08:55, Richard Shann wrote: On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote: Thanks Richard, I never used it and I ignored its existence. I'll add that directory to the path in .bashrc. In light of the further steps it isn't useful to add that directory to the PATH (because the command will not work unless the it is the cwd). It is just the web page instructions that need updating to read cd $LILYPOND_GIT lily-git.tcl rather than Type (or copypaste) into the Terminal: lily-git.tcl as at present. It's not worth a new iso update IMO. right - the iso seems to be working just fine - with guest extensions working out of the box (and that cyrillic thing too). BTW my first make failed in the docs - is that expected? Richard Just to check you did a 'make' before you 'make doc' didn't you? I haven't tried make doc I just did make I nearly emailed about it at the time and then I realized that I had already made the first (small) mod to the code, adding (chordCompact ,boolean? Draw chord symbols in a compact fashion?) into define-context-properties.scm and so (as this includes a bit of documentation) I realized that I had blundered by not doing the make at the outset, before starting to modify code, so as to be sure that things were good to start with. I described the problem as being to do with building docs just because of the error message, but I can't reconstruct this (by doing make on the master branch) because lilypond.org is down, so I can't get back to the web page which details the autogen and configure steps needed ... Hence my diffidence about mentioning this in the first place. Once the dust has settled I'll come back to it. Richard It will fail then otherwise. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Changes.tely updated - 2.19.x up to September 2014 (issue 147860043 by pkx1...@gmail.com)
Reviewers: ,
Message:
Hello, if those that have put in these recent features and enhancements
that are listed in this checkin to the 'Changes' list can come up with
some minimal examples to illustrate them I'd be very appreciative.
I don't pretend to understand all the enhancements and if you think I
have missed any or some are not appropriate and needn't be listed let me
know.
Description:
Changes.tely updated - 2.19.x up to September 2014
Since June 2014.
Added Tracker issues
2245/4005, 2813/3966, 3186, 3734/3825/3834,
4015, 4022, 4038, 4042, 4047, 4056, 4063,
4083, 4086, 4094 and 4097.
Included @lilypond examples where appropriate
Please review this at https://codereview.appspot.com/147860043/
Affected files (+90, -0 lines):
M Documentation/changes.tely
Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index
37df7f9f75450e8fc62f7f2ab5837fad4ceb5857..c53b4bbf9cd0c0fb80d5416a35f96429578ad45b
100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -60,6 +60,96 @@ which scares away people.
* only show user-visible changes.
@end ignore
+@item It is now possible to override the @code{text} property of
+chord names.
+
+@example
+\new ChordNames \chordmode {
+ a b c:7
+ \once \override ChorName.text = #foo
+ d
+}
+@example
+
+@item Improved horizontal alignment when using @code{TextScripts},
+with @code{DymanicTexts} or @code{LyricTexts}.
+
+@item A new command @code{\magnifyStaff} has been added which scales staff
+sizes, staff lines, bar lines, beamlets and horizontal spacing generally
+at the @code{Staff} context level. Staff lines are prevented from being
+scaled smaller than the default since the thickness of stems, slurs, and
+the like are all based on the staff line thickness.
+
+@item @code{InstrumentName} now supports @code{text-interface}.
+
+@item There is now support for controlling the @q{expression level} of
+MIDI channels using the @code{Staff.midiExpression} context property.
+The property accepts a number value between @code{0.0} and @code{1.0}.
+
+@example
+\score {
+ \new Staff \with {
+midiExpression = #0.3
+midiInstrument = #clarinet
+ }
+ @dots{} music @dots{}
+ \midi { }
+}
+@end example
+
+
+@item It is now much easier for LilyPond to use alternative @q{music}
+fonts other than the default Ementaler.
+
+@item Grobs and their parents can now be aligned separately allowing
+more flxeibility for grob positions. For example the @q{left} edge of a
+grob can now be aligned on the @q{center} of its parent.
+
+@item Improvements to the @code{\partial} command have been made to
+avoid problems when using multiple, parallel contexts -- including bar
+checks.
+
+@item Numbers attached to clefs(indicating clef transposition) are now
+aligned seperately rather than simply centered against the clef glyph.
+
+@item @code{\chordmode} can now use @code{ } and @code{ }
+constructs.
+
+@item The @code{NullVoice} context is now @q[below} @code{Score}.
+
+@item Improvements made to smob functionality. Basic smob types
+@code{Smob1}, @code{Smob2} and @code{Smob} with minimal data
+requirements and no separate representation on the heap can be created
+and they can now be called like functions.
+
+@item
+A new command @code{\tagGroup} has now been added. This compliments
+the existing @code{\keepWithTag} and @code{removeWithTag} commands. For
+Example:
+
+@example
+\tagGroup #'(violinI violinII viola cello)
+@end example
+
+declares a list of @q{tags} that belong to a single @q{tag group}.
+
+@example
+\keepwithTag#'violinI
+@end example
+
+Is now only concerned with @q{tags} from @q{violinI}'s tag group.
+
+Any element of the included music tagged with one or more tags from the
+group, but @emph{not} with @var{violinI}, will be removed.
+
+@item
+The @code{\addlyrics} function now works with arbitrary contexts
+incuding @code{Staff}.
+
+@item
+@code{Rest_collision} grobs now ignore other grobs that do not use the
+@code{Note_column} interface.
+
@item
The @code{thin-kern} property of the @code{BarLine} grob has been
renamed to @code{segno-kern}.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev not accepting paste from host clipboard
On 21/09/14 10:30, Richard Shann wrote: On Sun, 2014-09-21 at 09:14 +0100, James wrote: On 21/09/14 08:55, Richard Shann wrote: On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote: Thanks Richard, I never used it and I ignored its existence. I'll add that directory to the path in .bashrc. In light of the further steps it isn't useful to add that directory to the PATH (because the command will not work unless the it is the cwd). It is just the web page instructions that need updating to read cd $LILYPOND_GIT lily-git.tcl rather than Type (or copypaste) into the Terminal: lily-git.tcl as at present. It's not worth a new iso update IMO. right - the iso seems to be working just fine - with guest extensions working out of the box (and that cyrillic thing too). BTW my first make failed in the docs - is that expected? Richard Just to check you did a 'make' before you 'make doc' didn't you? I haven't tried make doc I just did make I nearly emailed about it at the time and then I realized that I had already made the first (small) mod to the code, adding (chordCompact ,boolean? Draw chord symbols in a compact fashion?) into define-context-properties.scm and so (as this includes a bit of documentation) I realized that I had blundered by not doing the make at the outset, before starting to modify code, so as to be sure that things were good to start with. I described the problem as being to do with building docs just because of the error message, but I can't reconstruct this (by doing make on the master branch) because lilypond.org is down, so I can't get back to the web page which details the autogen and configure steps needed ... Hence my diffidence about mentioning this in the first place. Once the dust has settled I'll come back to it. Richard It will fail then otherwise. James from $LILYPOND_GIT using an 'out of tree build' mkdir build ./autogen.sh --noconfigure cd build ../configure --disable-optimising make make doc The --disable-optimising gives a more robust set of test when using 'make'. creating a build dir inside $LILYPOND_GIT has the advantage of just being able to nuke it if you get into problems. Hope this helps James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x up to September 2014 (issue 147860043 by pkx1...@gmail.com)
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode69
Documentation/changes.tely:69: \once \override ChorName.text = #foo
ChordName.text
Maybe make this @lilypond? If you keep it example, you'll also need
to replace { with @{ and } with @}
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode72
Documentation/changes.tely:72: @example
More like @end example
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode75
Documentation/changes.tely:75: with @code{DymanicTexts} or
@code{LyricTexts}.
I think you want all of those without the final s. And it's DynamicText
rather than DymanicText.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode102
Documentation/changes.tely:102: fonts other than the default Ementaler.
Emmentaler. I'm not sure this makes sense without example or reference.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode106
Documentation/changes.tely:106: grob can now be aligned on the
@q{center} of its parent.
Is this properly documented anywhere? If not, it's a bit hearsay
without specifying at least that this goes via parent-alignment-X and
parent-alignment-Y (if I remember correctly).
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode108
Documentation/changes.tely:108: @item Improvements to the
@code{\partial} command have been made to
Bar checks are not a parallel context, but since this is really more a
bug fix than anything else, I'd just remove that item rather than haggle
over its wording.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode113
Documentation/changes.tely:113: aligned seperately rather than simply
centered against the clef glyph.
separately, but again I think that's more a bug fix than anything
else.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode120
Documentation/changes.tely:120: @item Improvements made to smob
functionality. Basic smob types
Internals. Does not belong into Changes.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode150
Documentation/changes.tely:150: @code{Rest_collision} grobs now ignore
other grobs that do not use the
I think that's again more of a bug fix than anything else. Basically,
it reduces the number of warnings.
I'd remove it rather than fix the spellings of the grob and interface
names ;)
https://codereview.appspot.com/147860043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x up to September 2014 (issue 147860043 by pkx1...@gmail.com)
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode127
Documentation/changes.tely:127: the existing @code{\keepWithTag} and
@code{removeWithTag} commands. For
@code{\keepWithTag} and @code{\removeWithTag}
https://codereview.appspot.com/147860043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x up to September 2014 (issue 147860043 by pkx1...@gmail.com)
Just some minor nitpicks, as I cannot speak about the details of the
recent changes.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode105
Documentation/changes.tely:105: more flxeibility for grob positions.
For example the @q{left} edge of a
s/flxeibility/flexibility/
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode118
Documentation/changes.tely:118: @item The @code{NullVoice} context is
now @q[below} @code{Score}.
'{' instead of '[' in front of 'below'
https://codereview.appspot.com/147860043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
Don Armstrong d...@debian.org writes: What is the current status of #1055[1] (support for Guile 2.0 in lilypond)? I'm currently working on it. There is a branch dev/guilev2 with the current work. Current objective is to make it through the test suite. Several crashes so far look like the memory management is borked. Debian is going to be dropping guile-1.8 completely, so in order for lilypond to be in the next Debian release (and rosegarden, and a few other things), I need to have it support guile 2.0 at least a month before freeze, which will likely happen in February at the latest. Support guile 2.0 by 2015: not sure. Support it in a manner that would be preferable to an installation using 1.8: rather dubious. Be released as stable version 2.20: unlikely. At best, we'll have a 2.20 branch only open to bug fixes and Guile 2.0 necessitated changes. But it seems feasible to get Guile 2.0 itself into the state needed to support LilyPond by the time of the freeze. Or get convincing admissions that it isn't there yet, possibly bargaining for a last-time inclusion of 1.8. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev not accepting paste from host clipboard
2014-09-21 11:30 GMT+02:00 Richard Shann rich...@rshann.plus.com: I described the problem as being to do with building docs just because of the error message, but I can't reconstruct this (by doing make on the master branch) because lilypond.org is down, so I can't get back to the web page which details the autogen and configure steps needed ... Hence my diffidence about mentioning this in the first place. It's now back online. But if you install the debian package lilypond-doc-html you can find the Contributor guide here: file:///usr/share/doc/lilypond/html/Documentation/contributor-big-page.html ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
MacUpdate - your app listing has been updated
[1][macupdate-logo.png] top background App Listing Updated Hi lilypond.org, We have updated your application listing for LilyPond 2.19.14-1 on [2]MacUpdate.com. Please take a moment to review your application's information to make sure that everything is correct. [3]View your updated app listing view your updated app You can [4]login to your Developer Account to reply to comments and view stats, or [5]submit new updates and changes to your app listing. [6]MacUpdate Desktop install compatability Desktop Install Compatability MacUpdate Desktop 6 is helping developers make it easier for users to fully install and use their apps. Download Desktop 6 and to ensure your app works with the Install link on our download pages. Advertise With MacUpdate The best Mac devs advertise their apps on MacUpdate.com becaue it's the most targeted, highly performing Mac app advertising you can find on the web. Contact Trevor to guarantee your annual ad campaigns get booked and expand your app's audience. Learn more view your updated app MacUpdate Desktop install compatability Questions? Contact our Content Update Team [7]upda...@macupdate.com. bottom background You are receiving this offer because you have an app listed on MacUpdate.com. Add us to your address book or white list to ensure reliable delivery. (c) 2014 MacUpdate LLC - All Rights Reserved 526 W. 14th St. #100 o Traverse City, MI 49684 References Visible links 1. http://www.macupdate.com/?utm_source=macupdateutm_medium=emailutm_term=LilyPondutm_content=appupdateutm_campaign=dev_emails 2. http://www.macupdate.com/?utm_source=macupdateutm_medium=emailutm_term=lilypondutm_content=appupdateutm_campaign=dev_emails 3. http://www.macupdate.com/app/mac/19024/lilypond?utm_source=macupdateutm_medium=emailutm_term=lilypondutm_content=appupdateutm_campaign=dev_emails 4. https://www.macupdate.com/member/login?utm_source=macupdateutm_medium=emailutm_term=lilypondutm_content=appupdateutm_campaign=dev_emails 5. http://www.macupdate.com/developers/update/?utm_source=macupdateutm_medium=emailutm_term=lilypondutm_content=appupdateutm_campaign=dev_emails 6. http://www.macupdate.com/desktop?utm_source=macupdateutm_medium=emailutm_term=lilypondutm_content=appupdateutm_campaign=dev_emails 7. mailto:upda...@macupdate.com Hidden links: 8. http://www.macupdate.com/advertise?utm_source=macupdateutm_medium=emailutm_term=lilypondutm_content=appupdateutm_campaign=dev_emails ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
On Sun, 21 Sep 2014, David Kastrup wrote: Don Armstrong d...@debian.org writes: What is the current status of #1055[1] (support for Guile 2.0 in lilypond)? I'm currently working on it. There is a branch dev/guilev2 with the current work. Current objective is to make it through the test suite. Several crashes so far look like the memory management is borked. Awesome; thanks for doing the hard work on this. I started looking into this myself, and quickly realized I was way over my head (and available time to commit to it). Debian is going to be dropping guile-1.8 completely, so in order for lilypond to be in the next Debian release (and rosegarden, and a few other things), I need to have it support guile 2.0 at least a month before freeze, which will likely happen in February at the latest. Support guile 2.0 by 2015: not sure. Support it in a manner that would be preferable to an installation using 1.8: rather dubious. Be released as stable version 2.20: unlikely. At best, we'll have a 2.20 branch only open to bug fixes and Guile 2.0 necessitated changes. OK. But it seems feasible to get Guile 2.0 itself into the state needed to support LilyPond by the time of the freeze. Or get convincing admissions that it isn't there yet, possibly bargaining for a last-time inclusion of 1.8. OK. I *might* be able to convince the guile maintainer to keep 1.8 just for lilypond, but that also might mean that I'll end up having to maintain guile 1.8 too. Could you point me at a list of guile 2.0 bugs which are affecting lilypond? Having that list handy would help me convince the guile maintainer (and also Debian's release managers and security) that there were valid reasons to keep guile 1.8 for another release of Debian. Thanks again. -- Don Armstrong http://www.donarmstrong.com I always thought violence didn't solve anything until one day it did. -- a softer world #470 http://www.asofterworld.com/index.php?id=470 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
Don Armstrong d...@debian.org writes: Could you point me at a list of guile 2.0 bugs which are affecting lilypond? Having that list handy would help me convince the guile maintainer (and also Debian's release managers and security) that there were valid reasons to keep guile 1.8 for another release of Debian. At the current point of time I cannot point to anything that I consider beyond workaround. There are a number of stunners (for a recent one, check out URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18495) that make it likely that no application really uses the C APIs for interfacing data into GUILE all that much. GUILE2 also has reverted to using the Boehm garbage collector. Let me quote from its FAQ at URL:http://www.hboehm.info/gc/faq.html: If my heap uses 2 GB on a 32-bit machine, won't every other integer or other random data be misinterpreted as a pointer by the collector? Thus won't way too much memory be retained? Maybe. Probably, if the collector is used purely conservatively, with no pointer layout information (such as use of GC_MALLOC_ATOMIC). With a gigabyte heap, you are clearly much better off on a 64-bit machine. Empirical evidence seems to suggest that some such applications work on a 32-bit machine, and others don't perform acceptably. LilyPond is a large application, and obviously lots of people are running 32bit systems (I am one of them). Some people are running LilyPond on large files: if the garbage collector goes out of commission on those files, they won't be happy. I am currently in the situation that when starting the regtests with 10 processes, the processes crash one by one, with the last one lasting a bit over a minute. Several of those crashes look like being garbage collection related (basically, memory is freed in spite of being still in use, actually the opposite of the situation described in the FAQ), and very hard to debug. It's not clear how long I'll take to wear down the bugs. Half of them are other things that go ugh, like GUILE being of the opinion it knows how to deal with various character encodings, reinterpreting strings as byte streams and vice versa in situations where it does not make sense. I'll probably have to tell GUILE everything is in Latin-1 as a first approach which will, of course, lead to its own share of problems. To be fair, most of them are already in GUILE1. But at least they are reasonably well-understood, as opposed to what GUILE2 does. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
On Sun, 21 Sep 2014, Don Armstrong wrote: OK. I *might* be able to convince the guile maintainer to keep 1.8 just for lilypond, but that also might mean that I'll end up having to maintain guile 1.8 too. Could you point me at a list of guile 2.0 bugs which are affecting lilypond? Having that list handy would help me convince the guile maintainer (and also Debian's release managers and security) that there were valid reasons to keep guile 1.8 for another release of Debian. Just for the record, the Debian bug for this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005 -- Don Armstrong http://www.donarmstrong.com It can sometimes happen that a scholar, his task completed, discovers that he has no one to thank. Never mind. He will invent some debts. Research without indebtedness is suspect, and somebody must always, somehow, be thanked. -- Umberto Eco How to Write an Introduction ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
On Sun, 21 Sep 2014, David Kastrup wrote: Don Armstrong d...@debian.org writes: Could you point me at a list of guile 2.0 bugs which are affecting lilypond? Having that list handy would help me convince the guile maintainer (and also Debian's release managers and security) that there were valid reasons to keep guile 1.8 for another release of Debian. At the current point of time I cannot point to anything that I consider beyond workaround. There are a number of stunners (for a recent one, check out URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18495) that make it likely that no application really uses the C APIs for interfacing data into GUILE all that much. Heh. Yeah... that's pretty bad. Probably following http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guile;submitter=d...@gnu.org is good enough, then. I am currently in the situation that when starting the regtests with 10 processes, the processes crash one by one, with the last one lasting a bit over a minute. Yeesh. It's not clear how long I'll take to wear down the bugs. Half of them are other things that go ugh, like GUILE being of the opinion it knows how to deal with various character encodings, reinterpreting strings as byte streams and vice versa in situations where it does not make sense. I'll probably have to tell GUILE everything is in Latin-1 as a first approach which will, of course, lead to its own share of problems. To be fair, most of them are already in GUILE1. But at least they are reasonably well-understood, as opposed to what GUILE2 does. Thanks for the additional information! (And sorry if my original e-mail sounded like I was pressuring y'all to do work; I'm just trying to keep lilypond in Debian.) -- Don Armstrong http://www.donarmstrong.com I always thought violence didn't solve anything until one day it did. -- a softer world #470 http://www.asofterworld.com/index.php?id=470 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
On Sun, 21 Sep 2014, David Kastrup wrote: Don Armstrong d...@debian.org writes: Could you point me at a list of guile 2.0 bugs which are affecting lilypond? Having that list handy would help me convince the guile maintainer (and also Debian's release managers and security) that there were valid reasons to keep guile 1.8 for another release of Debian. At the current point of time I cannot point to anything that I consider beyond workaround. There are a number of stunners (for a recent one, check out URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18495) that make it likely that no application really uses the C APIs for interfacing data into GUILE all that much. Heh. Yeah... that's pretty bad. Probably following http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guile;submitter=d...@gnu.org is good enough, then. I am currently in the situation that when starting the regtests with 10 processes, the processes crash one by one, with the last one lasting a bit over a minute. Yeesh. It's not clear how long I'll take to wear down the bugs. Half of them are other things that go ugh, like GUILE being of the opinion it knows how to deal with various character encodings, reinterpreting strings as byte streams and vice versa in situations where it does not make sense. I'll probably have to tell GUILE everything is in Latin-1 as a first approach which will, of course, lead to its own share of problems. To be fair, most of them are already in GUILE1. But at least they are reasonably well-understood, as opposed to what GUILE2 does. Thanks for the additional information! (And sorry if my original e-mail sounded like I was pressuring y'all to do work; I'm just trying to keep lilypond in Debian.) -- Don Armstrong http://www.donarmstrong.com I always thought violence didn't solve anything until one day it did. -- a softer world #470 http://www.asofterworld.com/index.php?id=470 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
David Kastrup d...@gnu.org writes: It's not clear how long I'll take to wear down the bugs. Half of them are other things that go ugh, like GUILE being of the opinion it knows how to deal with various character encodings, reinterpreting strings as byte streams and vice versa in situations where it does not make sense. Here is an example: ;(setlocale LC_ALL ) (define s (list-string (map integer-char '(20 200 2000 (with-input-from-string s (lambda () (let loop ((ch (read-char (current-input-port (if (not (eof-object? ch)) (begin (format #t ~d\n (char-integer ch)) (loop (read-char (current-input-port Without reactivating the outcommented setlocale line, this will crash. And it will not crash when defining s: GUILE is fine with defining strings with large characters. Strings are character-set agnostic. Instead it will crash on with-input-from-string: Backtrace: In ice-9/boot-9.scm: 157: 7 [catch #t #catch-closure 9552370 ...] In unknown file: ?: 6 [apply-smob/1 #catch-closure 9552370] In ice-9/boot-9.scm: 63: 5 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 4 [eval # #] In ice-9/boot-9.scm: 2320: 3 [save-module-excursion #procedure 956bea0 at ice-9/boot-9.scm:3961:3 ()] 3968: 2 [#procedure 956bea0 at ice-9/boot-9.scm:3961:3 ()] In unknown file: ?: 1 [load-compiled/vm /home/dak/.cache/guile/ccache/2.0-LE-4-2.0/tmp/grog.scm.go] ?: 0 [call-with-input-string \x14�\u07d0 ...] ERROR: In procedure call-with-input-string: ERROR: Throw to key `encoding-error' with args `(scm_to_stringn cannot convert wide string to output locale 84 #f #f)'. Why would GUILE convert the string to an _output_ locale, just to read it in again and convert it back according to an input locale? Since with-input-from-string and with-output-to-string are used liberally for working with character streams, the gratuitous encoding and decoding turns a well-defined operation into something totally opaque and mysterious. And it's not like the backtraces win a price for obviousness, either. GUILE-1.8 already aborts at the attempt of converting 2000 to a character. That's a clearcut limitation with understandable effects. But whatever you manage to turn into a character will then pass through strings or with-in/output-from/to-string or whatever else unmolested. GUILE-2.0, in contrast, accepts larger characters and then juggles around with them like hot potatoes. It just has no clear concept, and then let's some external library (iconv or whatever it was) loose on it in the hope that running enough good external code in some manner will result in something everybody should like. At least that's how it appears to me. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
Don Armstrong d...@debian.org writes: On Sun, 21 Sep 2014, David Kastrup wrote: Don Armstrong d...@debian.org writes: Could you point me at a list of guile 2.0 bugs which are affecting lilypond? Having that list handy would help me convince the guile maintainer (and also Debian's release managers and security) that there were valid reasons to keep guile 1.8 for another release of Debian. At the current point of time I cannot point to anything that I consider beyond workaround. There are a number of stunners (for a recent one, check out URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18495) that make it likely that no application really uses the C APIs for interfacing data into GUILE all that much. Heh. Yeah... that's pretty bad. Probably following http://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guile;submitter=d...@gnu.org is good enough, then. No, that does not make clear which problems can be worked around reasonably easily, or which are proposals or fixes unrelated to LilyPond (I mean, when I read code or write test programs while searching for the cause of a problem and hit on some unrelated bad stuff, that does not mean that LilyPond is affected). Thanks for the additional information! (And sorry if my original e-mail sounded like I was pressuring y'all to do work; I'm just trying to keep lilypond in Debian.) Yes, that would be very desirable. It's also worth noting that the current development model of GUILE seriously mislabels the stable branch. Basically the stable branch is where the normal developers work, while master is the experimental branch from Andy Wingo, the lead developer, which he works on without communicating with anybody else. If you take a look at URL:http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=NEWS;hb=stable-2.0 you'll find things like 208 * New deprecations 209 210 ** General 'uniform-vector' interface 211 212 This interface lacked both generality and specificity. The general 213 replacements are 'array-length', 'array-ref', and friends on the scheme 214 side, and the array handle interface on the C side. On the specific 215 side of things, there are the specific bytevector, SRFI-4, and bitvector 216 interfaces. 217 218 ** Use of the vector interface on arrays 219 ** 'vector-length', 'vector-ref', and 'vector-set!' on weak vectors 220 ** 'vector-length', 'vector-ref', and 'vector-set!' as primitive-generics 221 222 Making the vector interface operate only on a single representation will 223 allow future versions of Guile to compile loops involving vectors to 224 more efficient native code. 225 226 ** 'htons', 'htonl', 'ntohs', 'ntohl' 227 228 These procedures, like their C counterpart, were used to convert numbers 229 to/from network byte order, typically in conjunction with the 230 now-deprecated uniform vector API. 231 232 This functionality is now covered by the bytevector and binary I/O APIs. 233 See Interpreting Bytevector Contents as Integers in the manual. 234 235 ** 'gc-live-object-stats' 236 237 It hasn't worked in the whole 2.0 series. There is no replacement, 238 unfortunately. 239 240 ** 'scm_c_program_source' 241 242 This internal VM function was not meant to be public. Use 243 'scm_procedure_source' instead. Interesting bunch of changes in a stable release branch. Stuff like 923 ** `define-public' is no a longer curried definition by default 924 925 The (ice-9 curried-definitions) should be used for such uses. See the 926 manual for details. has also lead to annoyances. It is worth noting that the (ice-9 curried-definitions) module still is incomplete, and it's just with quite recent versions that the implemented functionality is not just buggy. I've replaced all of the places in LilyPond where the bugs hit with hand-expanded macros. That gets rid of a large number of problems that Ian Hulin tried to work around with symptom-based workarounds (that just repeated stuff in a different manner when it did not work in the intended manner). Note that at the current point of time I cannot name an absolute roadblock that could not get worked around. It's just that going through all the problems and finding solutions is like wading through molasses and is giving one headache after another. And I have no idea when things will be getting better. I've made quite a bit of progress in the last week, but it's not like I'm anywhere where I would say ok, now only few obscure problems remain. Basically, I can exercise the regtests in order to get the next 5 strange problems to work on, rinse and repeat. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
David Kastrup d...@gnu.org writes: GUILE-1.8 already aborts at the attempt of converting 2000 to a character. That's a clearcut limitation with understandable effects. But whatever you manage to turn into a character will then pass through strings or with-in/output-from/to-string or whatever else unmolested. GUILE-2.0, in contrast, accepts larger characters and then juggles around with them like hot potatoes. It just has no clear concept, and then let's some external library (iconv or whatever it was) loose on it in the hope that running enough good external code in some manner will result in something everybody should like. GUILE-2.2, by the way, _always_ encodes to UTF-8 upon encountering with-input-from-string. Why it would encode at all rather than just taking the values from the string, I have no idea. Now decoding input in UTF-8 to a string and then reencoding the string to UTF-8 does not necessarily lead to the same byte string, and LilyPond keeps the input parsed by the LilyPond parser and the input parsed by Scheme in synch by positioning at the respective offsets. The LilyPond parser interprets utf-8 itself (and gives out proper and detailed error diagnostics and stuff for ill-formed utf-8) from the byte stream input, and the Scheme parser works from an in-memory stream. The result is that I can persuade GUILE-2.0 into synchronizing the byte streams of LilyPond and Scheme parsing with some pain. But come GUILE-2.2, this road will be barred with the current approach, and file reading and parsing will have to be completely rewritten. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes.tely updated - 2.19.x up to September 2014 (issue 147860043 by pkx1...@gmail.com)
Thanks to those that checked. New patch uploaded
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode69
Documentation/changes.tely:69: \once \override ChorName.text = #foo
On 2014/09/21 09:59:37, dak wrote:
ChordName.text
Maybe make this @lilypond? If you keep it example, you'll also need
to
replace { with @{ and } with @}
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode72
Documentation/changes.tely:72: @example
On 2014/09/21 09:59:38, dak wrote:
More like @end example
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode75
Documentation/changes.tely:75: with @code{DymanicTexts} or
@code{LyricTexts}.
On 2014/09/21 09:59:37, dak wrote:
I think you want all of those without the final s. And it's
DynamicText rather
than DymanicText.
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode102
Documentation/changes.tely:102: fonts other than the default Ementaler.
On 2014/09/21 09:59:38, dak wrote:
Emmentaler. I'm not sure this makes sense without example or
reference.
Typo done. I could think to do was link to openlily.org. Not sure if
this is 'bad form' or not as it is not in our Doc as such but it is a
nice enhancement.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode105
Documentation/changes.tely:105: more flxeibility for grob positions.
For example the @q{left} edge of a
On 2014/09/21 10:20:40, marc wrote:
s/flxeibility/flexibility/
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode106
Documentation/changes.tely:106: grob can now be aligned on the
@q{center} of its parent.
On 2014/09/21 09:59:37, dak wrote:
Is this properly documented anywhere? If not, it's a bit hearsay
without
specifying at least that this goes via parent-alignment-X and
parent-alignment-Y
(if I remember correctly).
Maybe Marc H can give a simple example I could add here or perhaps give
a more 'technically correct' summary instead?
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode108
Documentation/changes.tely:108: @item Improvements to the
@code{\partial} command have been made to
On 2014/09/21 09:59:37, dak wrote:
Bar checks are not a parallel context, but since this is really more
a bug fix
than anything else, I'd just remove that item rather than haggle over
its
wording.
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode113
Documentation/changes.tely:113: aligned seperately rather than simply
centered against the clef glyph.
On 2014/09/21 09:59:37, dak wrote:
separately, but again I think that's more a bug fix than anything
else.
OK, removed (I really must install that spell check plug-in! to my
editor).
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode118
Documentation/changes.tely:118: @item The @code{NullVoice} context is
now @q[below} @code{Score}.
On 2014/09/21 10:20:40, marc wrote:
'{' instead of '[' in front of 'below'
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode120
Documentation/changes.tely:120: @item Improvements made to smob
functionality. Basic smob types
On 2014/09/21 09:59:37, dak wrote:
Internals. Does not belong into Changes.
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode127
Documentation/changes.tely:127: the existing @code{\keepWithTag} and
@code{removeWithTag} commands. For
On 2014/09/21 10:00:06, Jean-Charles wrote:
@code{\keepWithTag} and @code{\removeWithTag}
Done.
https://codereview.appspot.com/147860043/diff/1/Documentation/changes.tely#newcode150
Documentation/changes.tely:150: @code{Rest_collision} grobs now ignore
other grobs that do not use the
On 2014/09/21 09:59:37, dak wrote:
I think that's again more of a bug fix than anything else. Basically,
it
reduces the number of warnings.
I'd remove it rather than fix the spellings of the grob and interface
names ;)
Done.
https://codereview.appspot.com/147860043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
On Sun, 21 Sep 2014, David Kastrup wrote: Don Armstrong d...@debian.org writes: I'm just trying to keep lilypond in Debian. Yes, that would be very desirable. So it looks like the guile maintainer is going to be willing to ship guile 1.8 if lilypond doesn't support guile 2.0. So keep up the good work, but hopefully it won't be as dire of an emergency. -- Don Armstrong http://www.donarmstrong.com The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyDev not accepting paste from host clipboard
2014-09-21 9:55 GMT+02:00 Richard Shann rich...@rshann.plus.com:
On Sat, 2014-09-20 at 17:27 +0200, Federico Bruni wrote:
Thanks Richard, I never used it and I ignored its existence. I'll add
that directory to the path in .bashrc.
In light of the further steps it isn't useful to add that directory to
the PATH (because the command will not work unless the it is the cwd).
It is just the web page instructions that need updating to read
cd $LILYPOND_GIT lily-git.tcl
rather than
Type (or copypaste) into the Terminal:
lily-git.tcl
as at present.
It's working for me. I've added this line to ~/.bashrc:
# add lily-git to the PATH
PATH=$LILYPOND_GIT/scripts/auxiliar:${PATH}
Now lily-git.tcl works wherever I am on the terminal. And it's smart enough
to change to $LILYPOND_GIT.
No need to update the documentation.
The only difference is that the lilypond repositories are already included
in the ISO, so you don't see the Get source button.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)
Don Armstrong d...@donarmstrong.com writes: On Sun, 21 Sep 2014, David Kastrup wrote: Don Armstrong d...@debian.org writes: I'm just trying to keep lilypond in Debian. Yes, that would be very desirable. So it looks like the guile maintainer is going to be willing to ship guile 1.8 if lilypond doesn't support guile 2.0. So keep up the good work, but hopefully it won't be as dire of an emergency. Well, we need to get this over with eventually. Not least of all so that GUILE 2.x becomes more robust for and/or aware of the needs of large-scale applications with a thoroughly integrated C/C++ core. There is a group angling for Guile-emacs integration, and they have similar design/stability problems to contend with and similarly a problem integrating with an application that has its own ways and needs for dealing with encoding strings and buffers. It's good that we don't have a hard make-or-break line here because I just cannot tell how ready GUILE will be by the end of the year, and I am pretty sure that we won't have a LilyPond working with GUILE 2.0 _and_ declared stable by the end of the year. The branch for it, maybe. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
