Re: GOP2-4: add script for batch indenting Scheme files (issue 6450162)
John Mandereau john.mander...@gmail.com writes:
Il giorno lun, 20/08/2012 alle 10.11 +, d...@gnu.org ha scritto:
http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh
File scripts/auxiliar/fixscm.sh (right):
http://codereview.appspot.com/6450162/diff/1/scripts/auxiliar/fixscm.sh#newcode15
scripts/auxiliar/fixscm.sh:15: emacs -batch $@ --eval
${elisp_expression}
Can you verify that emacs -batch indeed obeys directory-local variables?
Otherwise the above info is quite off
This info is off whether Emacs -batch obeys dir-local variables or not:
from your comment on -devel the directory-local settings you propose
(indent-tabs-mode in scheme-mode) is not used by this script. I'm
resending a patch.
Sigh. I have _never_ been proposing indent-tabs-mode in scheme-mode,
and most certainly my patch proposal was _quite_ the opposite, with the
_opposite_ effect.
Please don't further spread that myth.
It is not my fault that the Emacs-written Lisp print form of
(indent-tabs-mode . nil) happens to be (indent-tabs-mode).
Yes, it looks like calling a function indent-tabs-mode in that _quoted_
alist. Emacs has no such function or minor mode. It only has the
imprudently named _variable_ indent-tabs-mode which is set to _nil_
() when the form written out by _Emacs_ into the .dir-locals.el file
is later interpreted as an alist. Emacs wrote that as a result of using
M-x add-dir-local-variable RET.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Waltrop travel details
The last travel details in a nutshell: Landline is +49-2309-782756, my mobile phone +49-16092087547. Address is Im Knäppen 63, Waltrop. OpenStreetMap does not even show it while Google Maps is quite accurate. If that is a concern to you, bring your own GPS device and fix it. If you are using public transport all the way to Waltrop Elmenhorst (bus station), you'll need fares from the local transport organization VRR, available in ticket vending machines (not in advance). From Dortmund Hbf: Einzelticket Preisstufe B, €4.90 From Düsseldorf: Einzelticket Preisstufe D, €12.00 Those tickets are _not_ valid for high-speed trains (ICE, IC, EC, Thalys). High-speed trains don't offer relevant time savings for those connections, tickets cost about double, and _don't_ include local transport like subways and buses. Train tickets from outside of the VRR area (like from Cologne) also don't include local transport. If you are looking at the train departure tables, make sure that they are yellow (the white ones are only for arrivals usually), and don't sport a large S watermark (large railroad stations tend to have separate departure tables for the glacially slow S-Bahn local transport). Usable trains from Düsseldorf to Dortmund tend to be called Regionalexpress or Stadtexpress and take about an hour. Inside of Dortmund Hbf, you enter the subway U41 direction Brambauer and take it to its end point Brambauer Verkehrshof, travel time 23 minutes (now is the time to call when you are arriving late or on the weekend when the bus service is spotty). From the subway end station, you can take the Bus 284 direction Waltrop, Am Moselbach, exiting it at Waltrop Elmenhorst. It does not come all that often: check the schedule in case it makes more sense to get yourself picked up in Brambauer already. If the bus _is_ handy, and you consider walking after taking the bus, those last 900m will be hard to find without a map printout. Basically you walk through the street that has its dead end at the bus station, then continue right until you come to a wooden horse. You take the path there and follow it until getting to the second farm house. The wooden horse is also the waymark for people arriving by car. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Waltrop meeting outline
Rodolfo Zitellini xhero...@gmail.com writes: I can confirm I will arrive from Fribourg Friday 24th at 15:21 in Dortmund, I still have figure out the time it will take with the U41. See the previous posting with the travel details. You'll need a type B local transport ticket. I will leave sometime in the morning of tuesday, as my plane in Cologne leaves at 14.44. I will be arriving by train, so if someone is based in Swiss or near we can arrange for the trip (or to share a car, as David proposed) I will bring my sleeping bag, should I bring a sleeping pad too? Makes things more flexible if it has a reasonable size. I would like to be present all day the 24th, but I am not sure I can make it the 23th. One topic I think would also be nice to touch is promoting LilyPond and how we can valorize all the music that is in Mutopia (I saw, for example, that there are much of Bach's organ works). Also we can continue to discuss on how to speed up compiling music - as this is one of the first things everyone notices (but it takes 40 minutes to create the book!). People are spoiled rotten. I've had moderate success promoting text-critical typesetting taking about that amount of time on an average computer for a thousand-page book. The established process I had problems competing with took about 8 weeks of outsourced manual labor (people working with scissor and paper) per iteration. With aesthetically inferior results (admittedly, at the time I did the presentation it was more of a toss-up). What are 40 minutes? At last, how are we organized for the food? I love cooking, so if needed I will gladly give a hand. There is not much of organization ahead. I'll start buying basic stuff soonish. The basic provisions I'll organize in advance will likely include substandard amounts of meat as my own expertise dealing with meat is quite limited. I expect to haggle out the details as more people arrive. It is a reasonable expectation that we'll order out at some date (Sunday noonish?), barbeque, do pizza (it's rather low effort to do dough/sauce), have noodles at one point of time. I'll certainly be glad for people pitching in with cooking/shopping, but one has to match the taken efforts to the number of eaters, so really complex food preparation is likely not feasible. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB dist-check failure
Graham Percival gra...@percival-music.ca writes:
Presumably the script was tested with bash, but was being run with
sh or dash? or something like that?
Which script?
git
--git-dir=/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/.git
show HEAD | head -100 out/RELEASE-COMMIT
make[5]: Leaving directory
`/main/src/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable'
cd
/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable
git ls-files
/main/src/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/.gitfilelist
/bin/sh: Syntax error: word unexpected (expecting then)
make[4]: *** [dist] Error 2
make[4]: Leaving directory
`/main/src/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable'
Traceback (most recent call last):
File test-lily/dist-check.py, line 137, in module
main ()
File test-lily/dist-check.py, line 129, in main
system ('cd %(builddir)s/ make DOCUMENTATION=yes dist' %
locals ())
File test-lily/dist-check.py, line 56, in system
raise Exception ('failed')
Exception: failed
make[3]: *** [unlocked-dist-check] Error 1
make[3]: Leaving directory `/main/src/gub'
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB dist-check failure
John Mandereau john.mander...@gmail.com writes: Le mercredi 22 août 2012 à 18:43 +0100, Graham Percival a écrit : Presumably the script was tested with bash, but was being run with sh or dash? or something like that? I tested make dist succesfully on my system, but without being sure if sh on my distro would behave as bash or not... Spaces in commannd outputs ùight also be a cause of this breakage... I'm reworking lines 43 and 54 of GNUmakefile.in to get rid of bashisms and quoting command outputs, and will submit an issue ASAP after having checked make dist. And people wonder why I am queasy about taking last-minute build-system changes into the stable branch. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Waltrop meeting outline
Jan Nieuwenhuizen jann...@gnu.org writes: I would like to arrive Friday early evening and stay till at least late Saturday night, possibly Sunday too. Excellent. How are you fitted regarding sleeping bag/mat/tent/camper? The two Musescore developers have booked into a hotel next town (Waltrop itself is pretty much booked solid), so it is conceivable that I need to organize transportation anyway (the bus connections on the weekend are a bit weak) and can ask them just where exactly they found cover. Of course, staying on the premise is more convenient, though compromising comfort. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with snippet 654 after 2.15.28
Phil Holmes em...@philholmes.net writes: Up until 2.15.27 http://lsr.dsi.unimi.it/LSR/Item?id=654 runs OK. Afterwards it seems to loop infinitely. I've tried convert-ly and it left the snippet unchanged. Could someone who understands what it's doing check whether a lily syntax change is needed, or is it revealing a bug? It is quite certainly issue 2240 Don't wrap EventChord around rhythmic events by default, with Fixed_2_15_28 label. The snippet relies on a rigid organisation of Music expressions that is no longer the same. The snippet does a wagonload of programming and convenience shortcuts that are not as much part of the snippet than of the writer's comfort space. My own impulse would be on rewriting it in a way depending less on the exact Music structure organisation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Waltrop meeting outline
pls p.l.schm...@gmx.de writes: Sleeping space is not an issue. I have a sleeping bag, a pad and a tent. But as I almost live in commuting distance I might go back home in the evening. When will you start tomorrow morning? I suppose that sometimes around 10:00 we'll gravitate from breakfast to the meeting room. I was going to order food for tomorrow, the outlet does Indian, Italian, Chinese, and German (Google finds them as URL:http://www.lieferheld.de/datteln/journal/, but I am not sure this is the best link. It does seem to show the menu.). So check out what you want to get from there. See you -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Waltrop meeting outline
pls p.l.schm...@gmx.de writes: I'll try to be in Brambauer at 11:09. If you haven't ordered food yet I'd take the Broccoli al Forno. Otherwise: no problem. If possible, call when you are in the subway. 02309-782756 landline, probably less reliable fallback 016092087547. I'll call the cook in the morning (probably getting the answering machine, but that should suffice). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Brain surgery on the make system
Phil Holmes em...@philholmes.net writes: John, Part of your re-org of the build system deleted the files Documentation/xx/included/GNUmakefile - where xx was cs, hu and zh. Those particular files were there in order to make the directories non-empty and thus trackable by git. Deleting them has led to warnings in the doc build system. When this was discussed in Feb this year, it was decided to go with empty directories rather than hacking the build system to avoid the warning. Could you restore these directories, please? One stupid way to keep those directories is to place an empty .gitignore file in them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Brain surgery on the make system
Phil Holmes em...@philholmes.net writes: - Original Message - From: John Mandereau john.mander...@gmail.com To: David Kastrup d...@gnu.org; Phil Holmes em...@philholmes.net Cc: Lily devel lilypond-devel@gnu.org Sent: Monday, August 27, 2012 4:03 PM Subject: Re: Brain surgery on the make system Hi Phil, I hoped that missing directories would be supported, and saw those warnings too but thought they were harmless and didn't bother. Adding dummy files is the easiest solution. 2012/8/27 David Kastrup d...@gnu.org: One stupid way to keep those directories is to place an empty .gitignore file in them. Good idea. As a bonus, some support for creating these .gitignore files could be added in Documentation/GNUmakefile:new-lang target. That ought not to be necessary, should it? Once they're part of the git repo, they should stay? That question is kind of hypothetical since git does not store directories as objects of their own. As far as git is concerned, an empty directory is an oxymoron. If a directory becomes empty during a commit, git will attempt to remove the directory and then consider it unregistered, whether or not the removal succeeds. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run fixcc + astyle2.02.1 (issue 6477062)
Graham Percival gra...@percival-music.ca writes: On Mon, Aug 27, 2012 at 10:21:53AM +, benko@gmail.com wrote: lily/include/skyline.hh:58: listBuilding *const result); I'd like to see the const removed (top-level const on function parameter types are ignored), but that may be the target of another patch. Not exactly correct: they are not part of the function signature (like result isn't), but they are relevant in the actual function, uh, declaration? I mean the thing when the function body follows. Good idea! However, that would be a more intelligent modification, which doesn't fit with fixcc's mandate. At the moment I just want to move forward with the automatic formatting. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The currently still assembled part of the team in Waltrop
Han-Wen Nienhuys hanw...@gmail.com writes: Everyone with eyes closed for lack of sleep? I was sitting on a couch discussing MusicXML exports with the guys from Philomenos (sp?) with Janek snoring right beside us. Graham had already dragged himself out of bed again if I remember correctly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The currently still assembled part of the team in Waltrop
Thomas Morley thomasmorle...@googlemail.com writes: 2012/8/27 David Kastrup d...@gnu.org: Han-Wen Nienhuys hanw...@gmail.com writes: Everyone with eyes closed for lack of sleep? I was sitting on a couch discussing MusicXML exports with the guys from Philomenos (sp?) with Janek snoring right beside us. Philomelos - http://philomelos.net/intro So much for myself being awake... Thanks! -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Waltrop meeting outline
Graham Percival gra...@percival-music.ca writes: On Thu, Aug 23, 2012 at 09:25:55PM -0300, Han-Wen Nienhuys wrote: Change font license from GPL to dual licensed OFL / GPL (see http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=OFL_web) We have agreement of this from the people who were here: Author: Janek Warchol lemniskata.bernoull...@gmail.com Author: Jan Nieuwenhuizen jann...@gnu.org Author: Marc Hohl m...@hohlart.de (*) IIRC, it was also agreed by those present that it would be a good idea to change to GPL with font exception for the GPL part of the dual licensing so that people would not prefer OFL merely because it fit font usage requirements better. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
m...@mikesolomon.org m...@mikesolomon.org writes: On 28 août 2012, at 06:08, k-ohara5...@oco.net wrote: Still works well, still the same speed, and now the code makes much more sense. The 25% extra time required to set a short score goes down if I \override Accidental #'vertical-skylines = #'() \override TextScript #'vertical-skylines = #'() \override TextScript #'horizontal-skylines = #'() \override Script #'vertical-skylines = #'() ... seemingly in proportion to the number of objects for which I give up detailed skylines. It may be worth it from a UI perspective to come up with a \cruderVerticalSkylineApproximationsForFasterCompilation command (or something of that ilk). I am bad at UI stuff, so I'll let someone else think of a good thing to call this and good vertical-skylines to override (you should set them to ly:grob::simple-vertical-skylines-from-stencil instead of '()). The list you have above looks like a good start - I'd add LyricText to it as well. Janek would be able to come up w/ an exhaustive list. After the simplification, many functions in skyline- and skyline-pair.cc are unused, and thus untested : left(), right(), intersects(), smallest_shift(), is_singleton(), invert(). Got rid of the cruft in staging. Most utility functions are a dime a dozen. Using them intelligently is what's hard. So people can just rewrite these things if they need them. The art is to create one that can do the job of a dozen, in an understandable way. A strictly limited number of versatile building blocks both conceptually simple as well as simple to use and providing completely coverage are what constitutes good APIs, and we should strive to have a set of those available from the Scheme side. People should program a simple C++ function if they need it is not being fair to our high-level users. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
James pkx1...@gmail.com writes: Hello, On 28 August 2012 08:17, Graham Percival gra...@percival-music.ca wrote: Let's make a list of tasks we want, then make sure that we're doing them on sensible computers. - Patchy staging-merge: powerful computer, no fixed internet connection. Every 6 hours? - Patchy test-patches: powerful computer, fixed internet connection, lots of free space to host the regtest comparisons. Every 6 hours? - translation documentation building: relatively slow computer, fixed internet connection. Every 24 hours? anything else? what computers do we have available? As you know you have mine that already does test-patchy (manually) and has done 'staging-merge' but it has no real bandwidth to offer 'hosting' or 'remote access' to other users - it sits at home behind a bog-standard DSL router. So it's essentially a 'push-only' server so to speak - hence the reason it was ok for Patchy merge. But unless I can work out how to get access through the DSL router (I've not checked) it isn't really helpful for those devs that might want to tweak and test updated scripts. Technically there's no reason why I couldn't allow ssh access via a terminal session, I just haven't bothered to figure out how to set up port forwarding on the router properly yet. The main beef is getting a dyndns setup where your changing IP address keeps associated with the same outside name. dyndns.org is something you can register on, and most routers have options for notifying a dynamic ip dns server. Without a fixed entry point (in this case, a fixed name), outside access is hard to implement. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Stub for ly to xml export using engravers
John Mandereau john.mander...@gmail.com writes: 2012/8/27 Han-Wen Nienhuys hanw...@gmail.com: Note that you can plug into the music event stream directly. That will give you an overview of all events. This sounds a nice idea, but I don't know how to do this, I started (re)reading Erik Sandberg's thesis and then guess it'll be easy to dig out a starting point from current Lily code. BTW writing an exporter (be it to xml or other) would be a good excuse for starting documenting this in Extending manual. I don't think the music stream actually exists. Music expressions are turned into stream events while iterating them in a given global context, and you can try to listen to all events. Things like the part combiner do something like that. But it is all a very dynamic operation, and it happens with _every_ call of ly:interpret-music-expression, and the actual conversion to stream events depends very much on the global context this happens in ($defaultmidi is totally different from $defaultlayout, for example). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Web glitch
Francisco Vila paconet@gmail.com writes: Hello, I have noticed that our nice round corners are now square, see attached image taken when using Firefox 14.0.1 in Ubuntu GNU/Linux. At least Apple won't sue us then for its rounded rectangle design patent. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Francisco Vila paconet@gmail.com writes: 2012/8/28 David Kastrup d...@gnu.org: The main beef is getting a dyndns setup where your changing IP address keeps associated with the same outside name. dyndns.org is something you can register on, and most routers have options for notifying a dynamic ip dns server. Is this easy when compared to getting a fixed IP from your ISP (which costs money)? Just asking. Depending on registering at a service and keeping up a subscription always is a hassle. A fixed outside name/IP from your ISP will certainly require fewer questions to address and answer. It makes changing ISP more of a hassle, though. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
Graham Percival gra...@percival-music.ca writes: Let's make a list of tasks we want, then make sure that we're doing them on sensible computers. - Patchy staging-merge: powerful computer, no fixed internet connection. Every 6 hours? - Patchy test-patches: powerful computer, fixed internet connection, lots of free space to host the regtest comparisons. Every 6 hours? - translation documentation building: relatively slow computer, fixed internet connection. Every 24 hours? anything else? what computers do we have available? Generation of profiling data (configure LilyPond with --enable-profiling and run it on a large test score) and graphical(?) presentation of the results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Assertion failure
m...@mikesolomon.org m...@mikesolomon.org writes: Hey all, With --disable-optimisation passed to configure, Janek's score at: www.mikesolomon.org/tota-pulchra.zip fails with the assertion failure on line 252 of the current grob-property.cc assert (value == SCM_EOL || value == marker); I started a git bisect but have no clue when the first good commit is - it hits this failure at least as far back as June 20th. I'm a bit short on time but could someone do some snooping to try and figure out what the problematic commit is? Not sure it's not a case of historical nonsense. Cf. URL:http://codereview.appspot.com/6449126/diff/1003/lily/grob-property.cc#newcode254 -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly problem
Marc Hohl m...@hohlart.de writes: Hello list, my current work on bar lines is ready for uploading to rietveld (due to the recent amount of work in Waltrop), but ... Since some bar lines have to be renamed, I wrote a rule for 2.17.1 (which works, by the way ;-) When I apply convert-ly with sh scripts/auxiliar/update-with-convert-ly.sh I got some messages convert-ly: Processing `ly/script-init.ly'... Applying conversion: 2.17.0, 2.17.1 and therefore changes like -@item blank-after-score-page-force -@funindex blank-after-score-page-force +@item blank-after-score-page-penalty +@funindex blank-after-score-page-penalty which certainly should *not* be included in the upload. Why not? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The currently still assembled part of the team in Waltrop
Phil Holmes m...@philholmes.net writes: - Original Message - From: m...@mikesolomon.org To: Phil Holmes m...@philholmes.net My wife said that everyone looks like geeks. There are 3 exceptions. You can't leave us hanging like that!! I hope I wasn't in the exceptions!!! Cheers, MS No. 2 were 4-legged and one was female. The female plays MTG. Among the 4-legged ones, Fridolin is the one who is likely to hop on the pedestal (partly against desperate attempts of his rider to keep him off) and stay there for hours. He is mostly kept in the stable because he ignores every fence and has a pretty solid technique for slipping under them without getting too much of a shock. Winni is a Haflinger, and the embodiment of laziness. When Conny bought her, she was told that she went A tournaments for jumping at one time, but did not think much of it. Then there was a fun tournament for young riders in the vicinity, and Conny thought this might be nice entertainment for some of her young students. fun tournament basically is things like carrying eggs or water while on horseback. However, the fun tournament happened on normal riding grounds, and the atmosphere apparently was fitting. Winni was piqued. She scanned the vicinity in search of the next obstacle. A piece of fence before the spectators was deemed suitable, and she trotted, then cantered towards it, clearing the fence (while losing the kid) right into the spectators who managed to get out of her way just in time. With all the parents of Conny's students watching. Winni can't rather stand close vicinity of other horses, but will still panic when left alone. Frido is not a socializer either. And he is essentially mute. After the foal was born, there was a period of a few weeks where he actually neighed. But he has become mute again soon afterwards. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly problem
Marc Hohl m...@hohlart.de writes: After searching a bit more, git grep blank-page-force shows several hits, but in 2.17.x, this should read blank-page-penalty, so I assume when master gets updated, then the convert rules should be applied, or am I totally on the wrong track? No, you aren't, but apparently somebody wrote the rule but did not bother to run update-with-convert-ly and committing the result before making a release. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly problem
Marc Hohl m...@hohlart.de writes: Am 28.08.2012 20:52, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: After searching a bit more, git grep blank-page-force shows several hits, but in 2.17.x, this should read blank-page-penalty, so I assume when master gets updated, then the convert rules should be applied, or am I totally on the wrong track? No, you aren't, That's nice ;-) but apparently somebody wrote the rule but did not bother to run update-with-convert-ly and committing the result before making a release. So can/shall I do something to correct this? I think this should be fixed quite soon, otherwise 'make doc' will fail for every language other than english, IIUC. You could just run update-with-convert-ly on a version of master with VERSION (probably manually reset, but not committing) to be still at 2.17.0 to avoid getting your own changeset in, reset VERSION and commit the resulting changes, then commit your changes, rerun update-with-convert-ly, commit again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The currently still assembled part of the team in Waltrop
Trevor Daniels t.dani...@treda.co.uk writes: Note the project lead being on the high horse after having wrapped up the 2.17.0 release for good. Thanks for the photo. Not as good as being there, but really nice to see. I know Graham and I think I can recognise you, David, but it would be good to be able to put names to the other faces. I see Jan has left already, or is he behind the camera? He left on the previous day, in weather conditions not favoring outdoor photographs. From left to right, this is Fridolin and David, Julien and Patrick from the Philomelos project, Rodolfo, Mike, John, Janek, Graham on top of Winni, and Conny, the principal, teacher, horse trainer and farm hand of the riding school. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in guile?
m...@mikesolomon.org m...@mikesolomon.org writes: Hey all, Could someone well-versed in guile try running primitive-load-path on the attached file with and without the last line commented. Without the last line commented, on my machine, I get: guile (primitive-load-path /home/mikesol/pleasework.lyaux) Backtrace: In standard input: 1: 0* [primitive-load-path /home/mikesol/pleasework.lyaux] standard input:1:1: In procedure string-number in expression (primitive-load-path /home/mikesol/pleasework.lyaux): standard input:1:1: Value out of range: 461 However, with the last line commented, everything works ok. This seems like a bug in Guile, but I wanna make sure that my input doesn't seem off before I report it to the list. Cheers, MS (define my-hash (make-hash-table 100)) (hashq-set! my-hash ae7d8fe61e91281e447a9e8c354114387284e14a0b4f3af8f392e1c9a943bd837ffb863f0602af 7.45493) Uh, you are aware _how_ one writes hexadecimal constants in Scheme? They start with #x. I am surprised you should get an error only on the last line. The lack of an error might be worth investigating _if_ it is reproducible. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bug in guile?
David Kastrup d...@gnu.org writes: m...@mikesolomon.org m...@mikesolomon.org writes: Hey all, Could someone well-versed in guile try running primitive-load-path on the attached file with and without the last line commented. Without the last line commented, on my machine, I get: guile (primitive-load-path /home/mikesol/pleasework.lyaux) Backtrace: In standard input: 1: 0* [primitive-load-path /home/mikesol/pleasework.lyaux] standard input:1:1: In procedure string-number in expression (primitive-load-path /home/mikesol/pleasework.lyaux): standard input:1:1: Value out of range: 461 However, with the last line commented, everything works ok. This seems like a bug in Guile, but I wanna make sure that my input doesn't seem off before I report it to the list. Cheers, MS (define my-hash (make-hash-table 100)) (hashq-set! my-hash ae7d8fe61e91281e447a9e8c354114387284e14a0b4f3af8f392e1c9a943bd837ffb863f0602af 7.45493) Uh, you are aware _how_ one writes hexadecimal constants in Scheme? They start with #x. I am surprised you should get an error only on the last line. The lack of an error might be worth investigating _if_ it is reproducible. And by the way: don't use hashq-set! on numbers: the result is undefined. You need to use hashv-set! to have equal values reliably map to the same hash bucket. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
Phil Holmes m...@philholmes.net writes: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Wednesday, August 29, 2012 10:25 AM Subject: Re: GUB upload error On Wed, Aug 29, 2012 at 10:16:18AM +0100, Phil Holmes wrote: For reference, I added the new group and added my gub user to that group, and the script still barfed. It can't change the properties of the files unless it has the permissions to do that, which it doesn't. Hmm, are you sure you rebooted? if your user is in group foo and bar, you should be able to change any file that you own to group foo or bar with no problems. Well, actually, I omitted that part of the instruction, since I could see my user in group lilypond... Your running processes don't change membership. Use id to see what the actual memberships are at the moment. What you can see in your system settings is just the starting membership for new sessions/logins. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB upload error
Graham Percival gra...@percival-music.ca writes: On Wed, Aug 29, 2012 at 10:16:18AM +0100, Phil Holmes wrote: For reference, I added the new group and added my gub user to that group, and the script still barfed. It can't change the properties of the files unless it has the permissions to do that, which it doesn't. Hmm, are you sure you rebooted? Logging in again should be sufficient. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: applying scheme indentation
Graham Percival gra...@percival-music.ca writes: As per GOP 2-4 - C++ and scheme indentation, we now have a fixscm.sh in the source tree. Running this was postponed pending Mike's monster skyline patch and possibly some sort of guile 2.0 thing. What's the status of the guile 2.0 patch? In particular, is it safe to run fixscm.sh now, or should that wait until ... ? I've uploaded the results of fixscm.sh: http://codereview.appspot.com/6499050 (I didn't add a code.google.com issue tracker for this) My preference is to push this now, and let Ian (or whoever) run fixscm.sh on their own scheme work. That does not help with rebasing, only with merging, and it is unlikely that merging Ian's work without rebasing is a good idea, as it likely has a longer history. But I'll defer to any scheme experts if they want to delay fixscm.sh by a week or two. Maybe Ian could push his current branch to some dev/* branch so that one can make a rough estimate what the costs of various ways of integration would turn out to be? fixscm.sh is basically an esthetic fix. We should do it when we are reasonably sure of no major resulting hassles. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Graham Percival gra...@percival-music.ca writes: At the Waltrop meeting, Janek proposed a number of interesting but potentially disruptive changes to the lilypond syntax. On a personal note, I really like most of them, but it will take a good chunk of work before they're ready to discuss on the main development list. Further complicating issues is that it quickly became apparent that I am not personally qualified to judge if a proposal is ready for main discussion. Wouldn't the purpose of a discussion be to present and discuss advantages and drawbacks? The question of _discussing_ a change is in my opinion quite different from _implementing_ a change. For example, one idea was to use postfix notation for (almost) everything. David pointed out that this would wreck havok on music functions, and I had to admit that I have no clue what a music function is. I mean, I know that there's \commands, but I have no clue what the difference is between \p, \relative, \staccato; other than their effect on the graphical+midi output. Well, this was actually more or less divided into several separate changes. One part was to _enforce_ having to write a directional modifier for postevents, meaning that whenever _ or ^ are allowed, you need to write at least -, like c4-(-[-\p-~ . This would admittedly simplify the parser (and other programs trying to parse LilyPond input), particularly when music functions like \tweak and \displayMusic and event functions like \bendAfter and \rightHandFinger get involved. Another part was to keep the undirectional syntax alive but assign different meaning to it on an as-case basis. With regard to providing a simpler interface to humans and computers, the proposals were somewhat conflicting in their direction, so it would make sense to discuss them separately where this happens to be the case. I'm not enthusiastic about cluttering -devel with preliminary discussions like teaching me about music functions vs. whatever the other thing are. I am not enthusiastic about cluttering -devel with non-preliminary discussions where everybody is assumed to have mastered the topics right from the start. There are reasons and implications for some of the design decisions, and part of the aims of such a discussion is leaving the participants with a better understanding about what is involved than the manual might provide. Frankly, the parser is a mess. Removing some convenience, like what I characterize as part one of his proposal, will provide at least some relief, at the cost of making previous syntax invalid and causing a less natural look of the music expressions. It is already possible to use this part of the syntax proposal as a _convention_. LilyPond just does not enforce it. At one point there was a mailing list on lilynet for syntax discussions, but I'm not certain if that's active. I could also make a new gnu.org mailing list... but either of those options would require anybody interested in that discussion to sign up for a new mailing list. Thoughts? opinions? alternatives that I haven't considered? These discussions are going to produce a *lot* of emails. And if they come to conclusions, they are going to produce effects on everybody. Including people using LilyPond as a service. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Janek Warchoł janek.lilyp...@gmail.com writes: On Wed, Aug 29, 2012 at 3:15 PM, David Kastrup d...@gnu.org wrote: Graham Percival gra...@percival-music.ca writes: At the Waltrop meeting, Janek proposed a number of interesting but potentially disruptive changes to the lilypond syntax. On a personal note, I really like most of them, but it will take a good chunk of work before they're ready to discuss on the main development list. Further complicating issues is that it quickly became apparent that I am not personally qualified to judge if a proposal is ready for main discussion. Wouldn't the purpose of a discussion be to present and discuss advantages and drawbacks? The question of _discussing_ a change is in my opinion quite different from _implementing_ a change. I suppose Graham meant that proposals presented for main discussion should be well-shaped and free of big and/or obvious problems. If there are big and/or obvious problems, the discussion would be short anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub upload failure
Phil Holmes em...@philholmes.net writes: OK - so it looks like I've now rsynched a few 100 MB of updates. I get this failure: git --git-dir downloads/lilypond/git push ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 Permission denied (publickey). I'm assuming that this is because GUB is trying to log in as you to the git repo and failing, because it has my key? a) is that right? Likely. b) should I find the gpercival@git bit and change this to my git username and c) what does this command do? Push the tag from downloads/lilypond/git to the main repository. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gub upload failure
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: lilypond-devel@gnu.org Sent: Wednesday, August 29, 2012 3:21 PM Subject: Re: Gub upload failure Phil Holmes em...@philholmes.net writes: OK - so it looks like I've now rsynched a few 100 MB of updates. I get this failure: git --git-dir downloads/lilypond/git push ssh+git://gperci...@git.sv.gnu.org/srv/git/lilypond.git/ refs/tags/release/2.17.1-1:refs/tags/release/2.17.1-1 Permission denied (publickey). I'm assuming that this is because GUB is trying to log in as you to the git repo and failing, because it has my key? a) is that right? Likely. b) should I find the gpercival@git bit and change this to my git username and c) what does this command do? Push the tag from downloads/lilypond/git to the main repository. I actually went ahead and found the line in the script, changed it and it then continued OK. However, it looks like the tag might already have been created locally. Sure, or it would not be possible to push it. git --git-dir downloads/lilypond/git tag -m -a release/2.17.1-1 git.sv.gnu.org/lilypond.git/release/unstable fatal: tag 'release/2.17.1-1' already exists I've never used tags and so need to do some research, but if you could tell me how to list and possibly delete tags in the local version of the repo, that would be helpful. git tag -d release/2.17.1-1 should suffice -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1
eluze elu...@gmail.com writes: Phil Holmes wrote Can I just say that this is the first release I've build and uploaded? Fingers crossed. congrats! however issue 2764 claims to solve the fingering problems of chords containing a second - I can not confirm this (picture attached)! http://lilypond.1069038.n5.nabble.com/file/n131656/2764.png and also issue 2284 seems to produce the old output what's going on? Time lag. git log -10 --all --graph --decorate gives: * commit ecf25f33aa4c02efda0694280e956c147f5006ae (origin/staging) | Author: Phil Holmes m...@philholmes.net | Date: Wed Aug 29 16:01:20 2012 +0100 | | Release: bump version. | * commit e98a84d3adfccbce3792b1176c937cc23589e669 |\ Merge: 58a49e2 bfc7fda | | Author: Phil Holmes m...@philholmes.net | | Date: Wed Aug 29 15:59:49 2012 +0100 | | | | Merge remote branch 'origin/release/unstable' into HEAD | | | * commit bfc7fdae57842d561568d1516337ce60e9aa8be0 (tag: release/2.17.1-1, origin/release/unstable) | | Author: Graham Percival gra...@percival-music.ca | | Date: Tue Aug 28 08:29:54 2012 +0100 | | | | Release: update news. | | * | commit 58a49e2c9dd187063f479389376705391d817ad3 | | Author: Marc Hohl m...@hohlart.de | | Date: Sun Aug 26 11:04:54 2012 +0200 | | | | Issue 1236: CG+scripts should use $LILYPOND_GIT | | * | commit 66a7c3e925cbc1a34eaad04f80d4bc42ad9834ac (origin/master, origin/HEAD) | | Author: Mike Solomon m...@apollinemike.com | | Date: Wed Aug 29 10:22:31 2012 +0200 | | | | Uses FingeringColumn to avoid collisions of overlapping Fingerings. | | * | commit 2a6d112286bfaabe36ef54fc655821cd87a91f4b | | Author: Mike Solomon m...@apollinemike.com | | Date: Wed Aug 29 10:14:16 2012 +0200 | | | | Adds OctavateEight to the avoidance grobs of the Beam_collision_engraver | | * | commit b0f94fb2156046b5fc721f271d55e2feb788167d | | Author: Mike Solomon m...@apollinemike.com | | Date: Wed Aug 29 10:06:36 2012 +0200 | | | | Extracts Accidentals for AccidentalPlacements in the side-position-interface. | | | | Because AccidentalPlacements have no height, this makes sure that all | | accidentals are accounted for in case an engraver missed them. | | * | commit 1cdcb2f73f35834fef5cbbc2a6647a11ae468f85 | | Author: Marc Hohl m...@hohlart.de | | Date: Tue Aug 28 22:52:24 2012 +0200 | | | | apply scripts/auxiliar/update-with-convert-ly.sh | | * | commit e6073c719af153e80ba9f31ed96040a3782a180a (HEAD, master) |/ Author: Mike Solomon m...@apollinemike.com | Date: Tue Aug 28 09:45:58 2012 +0200 | | Get rid of unused Skyline and Skyline_pair functions | * commit 1218da693e22c42b9f78074ad4d8f4a9151855c4 | Author: Keith OHara k-ohara5...@oco.net | Date: Wed Aug 15 23:01:36 2012 -0700 | | Properties to control placement of accidentals in KeySignatures | So since Phil took a bit of time after forking the unstable release branch to finish making the release, there are about 9 commits marked Fixed_2_17_1 which have to be changed to Fixed_2_17_2 since they missed the proper time to actually make it into 2.17.1. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2790 in lilypond: Patch: bar-line interface part 2/2
Marc Hohl m...@hohlart.de writes:
Am 29.08.2012 21:43, schrieb lilyp...@googlecode.com:
Updates:
Labels: -Patch-new Patch-needs_work
Comment #3 on issue 2790 by pkx1...@gmail.com: Patch: bar-line
interface part 2/2
http://code.google.com/p/lilypond/issues/detail?id=2790#c3
Patchy the autobot says: lots of: +programming error: Parsed object
should be dead: #Context_mod ((remove Axis_group_engraver) (remove
Hara_kiri_engraver) (consists Hara_kiri_engraver) (push
VerticalAxisGroup #t remove-empty) (description Remove staves which
are considered to be empty according to the list of interfaces set
by @code{keepAliveInterfaces}.))
I don't understand this error messages, and I didn't see any of them
during the
make test-baseline ... make test-redo
cycle; even
make doc
succeds. Any hints where these errors come from?
You need to configure with --disable-optimising (which does not make a
whole lot of sense) and run with -ddebug-gc.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1 regtests
m...@mikesolomon.org m...@mikesolomon.org writes: The regtest that worries me most is les-nereides.ly. There is a comment starting on line 827 of axis-group-engraver.cc from Joe (vintage 2008) that describes this scenario. It's just that excess spacing has always hid it. It is now the time to tackle it head on, as w/ the new skyline patch this type of scenario will come up more often. You appear worried about the slur through the fingerings. Yes, that is an ugly collision. But it is merely a collision. Much more worrying in my opinion is that the staffs in the first third of the page are crammed into each other so tightly that it becomes quite hard to guess which of the interleaved material belongs to top and which to bottom system. This generally looks like a non-existent staff-staff-spacing only kept apart by collision avoidance. We _really_ need a smart padding strategy reducing this effect which is _far_ too pronounced to produce readable scores. And perhaps double-check that staff-staff-spacing is actually doing its part in keeping the skylines at a distance. I somewhat doubt it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.17.1 regtests
Janek Warchoł janek.lilyp...@gmail.com writes: On Thu, Aug 30, 2012 at 12:44 AM, David Kastrup d...@gnu.org wrote: m...@mikesolomon.org m...@mikesolomon.org writes: The regtest that worries me most is les-nereides.ly. There is a comment starting on line 827 of axis-group-engraver.cc from Joe (vintage 2008) that describes this scenario. It's just that excess spacing has always hid it. It is now the time to tackle it head on, as w/ the new skyline patch this type of scenario will come up more often. You appear worried about the slur through the fingerings. Yes, that is an ugly collision. But it is merely a collision. Much more worrying in my opinion is that the staffs in the first third of the page are crammed into each other so tightly that it becomes quite hard to guess which of the interleaved material belongs to top and which to bottom system. This generally looks like a non-existent staff-staff-spacing only kept apart by collision avoidance. We _really_ need a smart padding strategy reducing this effect which is _far_ too pronounced to produce readable scores. I definitely agree. Actually, a while ago i have posted an idea of how the solution might look like: http://www.freeimagehosting.net/tsr21 and the description http://lists.gnu.org/archive/html/lilypond-devel/2012-03/msg00507.html I was a bit surprised to see only moderate amount of interest. How do you like this area approach? Not all that much. The examples are simplistic; actually a multi-scale approach is warranted: you want collision avoidance at the smallest scale, and clearance at all scales in between, not just at the line level. With nereides, one problem actually is that the padding is vertical padding. This makes the following line pairs considered as having the same distance: - - \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ And we actually need _more_ clearance horizontally since staff line direction favors optically distinguishing vertically adjacent elements from different staffs. We have a way to pad skylines horizontally, but I think that the amount needs to be _quite_ more _iff_ we are trying to determine the spacing between _independent_ staffs. I think the interstaff horizontal padding values should be moderate inside of a treble/bass PianoStaff or ChoirStaff (less need for padding if the staffgroup has a continuity of pitches), higher within an arbitrary StaffGroup, and even higher between different systems. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2793 in lilypond: Fret diagrams - end lines too thin
lilyp...@googlecode.com writes: Comment #3 on issue 2793 by philehol...@gmail.com: Fret diagrams - end lines too thin http://code.google.com/p/lilypond/issues/detail?id=2793 Think this needs back-porting to 2.16. We'll need a 2.16-1 at some point in the future, I'm assuming. For some reason, I don't even see this comment #3 on the web site. Did you delete it already? At any rate, I had not admitted the problematic change into 2.16.0, so while we certainly do need 2.16.1 in due time, it is not because of this issue. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes:
On Wed, Aug 29, 2012 at 10:15 AM, David Kastrup d...@gnu.org wrote:
For example, one idea was to use postfix notation for (almost)
everything. David pointed out that this would wreck havok on music
functions, and I had to admit that I have no clue what a music
function is. I mean, I know that there's \commands, but I have no
clue what the difference is between \p, \relative, \staccato; other
than their effect on the graphical+midi output.
Well, this was actually more or less divided into several separate
changes.
One part was to _enforce_ having to write a directional modifier for
postevents, meaning that whenever _ or ^ are allowed, you need to write
at least -, like c4-(-[-\p-~ . This would admittedly simplify the
parser (and other programs trying to parse LilyPond input), particularly
when music functions like \tweak and \displayMusic and event functions
like \bendAfter and \rightHandFinger get involved.
For example, I understand that requiring '-' for every post event
would simplify the parser. At the same time, it is not clear to me
what benefit simplifying that part of the parser will bring us.
I am currently working on unifying event functions (of which there are
not many yet, but they are a natural complement to event variables which
can be used without - before them), music functions, and scheme
functions, basically _first_ evaluating the function, _then_ deciding
its type, similar to the way \xxx works. This is tricky when taking a
look at things like
\displayMusic c \tweak #'color #red c
as opposed to
\displayMusic c \tweak #'color #red \p
since you get the semantic values for making the required decisions in
the syntax rather late.
Is there a complete proposal of what is on the drawing board? Barring
that, is there a list of (perceived) problems in the current
syntax/parser?
The possible values for music following a skipped optional argument are
constrained to music parseable without lookahead because the decision
for skipping requires evaluating the music expression first before
letting the parser change state or pushing back a synthetic token which,
again, is only possible when there is no lookahead token yet.
This is stalling things like
URL:http://code.google.com/p/lilypond/issues/detail?id=2067 and leads
to behavior surprising to users.
Frankly, the parser is a mess.
Jan and me are to blame for that. I think we spent too much time
musing over syntactic sugar, rather than coming up with less pretty
but simpler syntax.
Actually, for much of the current mess I am to blame since I retained
most of the shortcuts and prettiness while moving things to music
functions rather than hardwired syntax. Making those shortcuts a part
of user-writable extensions rather than hardwired into the parser makes
the parser quite more opaque. The LilyPond notation manual shows the
current LilyPond syntax definition from Bison. This move to generality
rather than hardwireness makes it a lot less handy and useful as a
reference.
It is a mess, and that should be clear to anyone who ever worked with
it. Unfortunately, according to git blame, there are very few such
persons. At the end of the day, probably only you and me are
qualified to judge on proposals from the perspective of parser.yy
And you would likely need a solid bout of catching up. No question that
you are in an excellent starting position for that, though.
I hope I can get to a state where I can reduce complexity again and/or
compress it into a few dense well-designed places.
$ git blame -e parser.yy|awk '{print $3;}'|sort|uniq -c|sort -n
[...]
1214 (han...@xs4all.nl
1335 (d...@gnu.org
Oops.
And if they come to conclusions, they are going to produce effects on
everybody. Including people using LilyPond as a service.
Before we go around proposing solutions, it would be good to know what
problems we are trying to solve.
The focus of Janek, as far as I remember, was people being able to read
valid LilyPond, people being able to write valid LilyPond. Of course,
there is a large variety of opinions what this entails.
For people like those from Scorio and Philomelos, outside programs being
able to read valid LilyPond and being able to write valid LilyPond is
important, a different consideration.
And I am also somewhat focused on the work it takes to make LilyPond
able to read valid LilyPond...
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy report
grenoui...@lilynet.net writes: 21:58:01 (UTC) Begin LilyPond compile, previous commit at e15e0d22810063b79da891bbf472ecc39d09c02c 21:58:15 From git.savannah.gnu.org:/srv/git/lilypond 5d2bd06..e15e0d2 master - master 201be86..e593c62 translation - translation 21:58:59 Merged staging, now at: e15e0d22810063b79da891bbf472ecc39d09c02c 21:59:01 Success:sudo -u lilybuild ./autogen.sh --noconfigure 21:59:37 Success:sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 21:59:47 Success:sudo -u lilybuild nice make clean 22:00:30 *** FAILED BUILD *** sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: 66a7c3e925cbc1a34eaad04f80d4bc42ad9834ac Current broken commit: e15e0d22810063b79da891bbf472ecc39d09c02c 22:00:30 *** FAILED STEP *** merge from staging Failed runner: sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 See the log file log-staging-nice-make--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt 22:00:31 Traceback (most recent call last): File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init_ [...] Grenouille currently seems to be wrong too often to be useful. Do you have a way of checking the integrity of its RAM? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy report
John Mandereau john.mander...@gmail.com writes: Il giorno ven, 31/08/2012 alle 00.38 +0200, David Kastrup ha scritto: grenoui...@lilynet.net writes: 21:58:01 (UTC) Begin LilyPond compile, previous commit at e15e0d22810063b79da891bbf472ecc39d09c02c 21:58:15 From git.savannah.gnu.org:/srv/git/lilypond 5d2bd06..e15e0d2 master - master 201be86..e593c62 translation - translation 21:58:59 Merged staging, now at: e15e0d22810063b79da891bbf472ecc39d09c02c 21:59:01 Success:sudo -u lilybuild ./autogen.sh --noconfigure 21:59:37 Success:sudo -u lilybuild /home/lilybuild/staging/configure --disable-optimising 21:59:47 Success:sudo -u lilybuild nice make clean 22:00:30 *** FAILED BUILD *** sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 Previous good commit: 66a7c3e925cbc1a34eaad04f80d4bc42ad9834ac Current broken commit: e15e0d22810063b79da891bbf472ecc39d09c02c 22:00:30 *** FAILED STEP *** merge from staging Failed runner: sudo -u lilybuild nice make -j2 CPU_COUNT=2 ANTI_ALIAS_FACTOR=1 See the log file log-staging-nice-make--j2-CPU_COUNT=2-ANTI_ALIAS_FACTOR=1.txt 22:00:31 Traceback (most recent call last): File /home/jmandereau/lilypond-extra/patches/compile_lilypond_test/__init_ This is a GCC segfault with GCC 4.4.7-2 (Debian unstable). On the contrary, the crash of make doc this morning on translation branch comes from an error in the Czech doc Texinfo source. Grenouille currently seems to be wrong too often to be useful. Do you have a way of checking the integrity of its RAM? I contacted the administrator for checking this, if I need to be physically present there we won't be able to check this before Monday. Some of the recent reports from Grenouille actually might suggest that it might be testing against an unrelated test-baseline. Perhaps you are taking wrong shortcuts, or are mixing up in-place and out-of-place builds or storing your test-baseline in a different place you read it from again? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: MusicXML and GuileV2
Han-Wen Nienhuys hanw...@gmail.com writes: On Thu, Aug 30, 2012 at 2:04 PM, David Kastrup d...@gnu.org wrote: This would also seem to form an excellent starting point for having LilyPond interpret MusicXML directly, bypassing converters as well as the ly parser. While this would not offer the full tweaking power and expressivity of ly, it would certainly be a good way of interfacing in a While sxml is certainly nice, I wouldn't overstate its usefulness. That was what starting point was about. The big problem with musicxml is that it has a data model that is completely different from anything inside lilypond, something that sxml does not help a lot with. But sxml is susceptible to things like Scheme syntax transforms and the (ice-9 match) module. The Scheme layer is quite powerful for juggling XML if it is in suitable form, and sxml seems designed for that. I'd like to have the same kind of power for music expressions, but that requires quite a bit of schemeification before it will be effective. At any rate, not having to go through the ly parser for MusicXML interpretation would be seriously useful. It would make it possible to use LilyPond in server/rendering tasks with security or resource implications, similar to PDF as a page description language as opposed to PostScript as a general programming language with graphical output. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes:
On Thu, Aug 30, 2012 at 9:02 AM, Graham Percival
gra...@percival-music.ca wrote:
That's why I wanted to make sure that proposals are in good
shape before discussing them on the main list. But there seems
to be general consensus that we want to discuss all proposals here
anyway, so I can roll with that.
For example, I understand that requiring '-' for every post event
would simplify the parser. At the same time, it is not clear to me
what benefit simplifying that part of the parser will bring us.
- people writing automated lilypond importers or exporters
(including algorithmic composition)
- people reading/writing lilypond scores manually (see below).
Automated writers are a non-argument: exporters can choose to prepend
the '-' always.
Automated readers - I am not very convinced about this. Reading .ly
correctly implies having a complete scheme interpreter at your
disposal. Or are we limiting ourselves to cases where there is no
escaped scheme (including any escapes that are present when using
identifiers) ?
Actually, at the Waltrop meeting I demonstrated using something like
bk = #{ \book { \include sourcefile.ly } #}
which leaves you with music, headers, and similar stuff. Music
functions have already done their work then. This is, of course, not
feasible for more complex scores, but one can just redefine the various
processing hooks and run LilyPond directly on the files to get at the
actual data to be typeset, foregoing most of the Scheme complications
(of course, you can't expect to interpret details like user-defined
context overrides and engravers, though they will be part of the data
structures as well).
Using LilyPond for reading LilyPond files (as opposed to parsers written
in Python) has the advantage of being rather thorough, and the
disadvantage to be tied into a single version (not all that helpful if
you want to write something like convert-ly).
Manual writers: can we make up our minds here? I've always been
against frivolous syntax for shortcuts (one example in particular is
the q for repetition). Why do we put in q for users to save some
keystrokes, and at the time propose to require a mostly redundant '-'
in front of zillions of postevents?
That was pretty much my reaction, both regarding q as well as this
proposal. However, mostly redundant is only a valid sentiment for the
first part of the proposal as Janek wanted to quite differentiate the
meaning depending on whether - was added or not, having both a postevent
meaning as well as a seemingly orthogonal non-postevent meaning (in the
various examples he made, the proposed non-postevent meanings were
different enough to actually require a per-case definition rather than
being derivable from the post-event meaning).
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Graham Percival gra...@percival-music.ca writes: The basic question is is it too late to change anything, and can we mitigate that pain?. I think it's not too late, particularly if the change can be done automatically, and particularly if we promise support for the new syntax. Alternatively, if it really _is_ too late to change anything, then let's declare that to be policy and make a promise not to change things. Change things from _what_? The last state as defined in the manual? The last state as haphazard as it happens to be? There is no point in making a promise not to change things if we don't have a reliable definition of what things even is. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Jan Nieuwenhuizen jann...@gnu.org writes: Han-Wen Nienhuys writes: Yes, I noticed that - it would be good to make all functions operating on arguments be verbs; similarly, \times could be renamed to something more verby. Guess what the current proposal is, I think I heard \tuplet (ugh). Wouldn't it be helpful if from the syntax one could tell functions from postfix operators simple statements? In most languages function invocations are easy to spot. I think in Perl you can have functions look like dead statements, but that's probably just making the argument better. offtopicI find it interesting that you are giving Perl while we are discussing readability./offtopic Ah, I was unclear. Right. LilyPond stands out /together/ with Perl in unreadability; these are the only two languages I know that can have functions look like statements. Hm? Scheme, C, C++, awk, Lua... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes:
On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup d...@gnu.org wrote:
Is there a complete proposal of what is on the drawing board? Barring
that, is there a list of (perceived) problems in the current
syntax/parser?
The possible values for music following a skipped optional argument are
constrained to music parseable without lookahead because the decision
I had to let this sink in for a bit, since I had completely missed
that a patch doing optional music arguments had went in. Had I noticed
in time, I probably would have complained (and we might have ended up
in a flamewar).
It was a matter of what's good for the goose, should be good for the
gander. The existing hardwired LilyPond syntax used a variety of
optional arguments (partly skipped explicitly using \default, partly
left out like with \relative { c' }). Bringing the preexisting syntax
within the scope of music functions meant making Scheme programmers stop
being second-class citizens who has to take what they are fed.
It also meant that the details of syntax between commands, a haphazard
connection of randomness, became unified and dependable.
I have become convinced that optional, unnamed arguments are not a
happy design decision, in any language. In Lily it's particularly
problematic, since we don't group function parameters. It was already
difficult to understand in
\func \a \b \c
Sure. Particularly if \c is \p instead. Separate function argument, or
post-event on \b?
I have spent many happy hours among my friends shift-reduce and his even
less likeable cousin reduce-reduce.
LilyPond syntax is not Scheme. It favors the writer's convenience.
[Some examples of more explicit argument syntax elided]
If the problem is the language being too implicit, or the parser being
too complex, they could be avenues to pursue.
The language is implicit, the parser is complex. If those were
_absolute_ criteria, Scheme/Lisp would be the only human-readable way of
formatting structured data and syntax to computers. In particular,
LilyPond input itself would be written and delimited like Scheme.
Instead, LilyPond has been designed to end up more or less free-flowing
like musicians talking to each other. In a way, its syntax is the
antithesis to Scheme. This comes at a price.
In a manner, part of this price has traditionally been we are the C++
folks, and we define the vocabulary with which you are allowed to talk
to LilyPond. This ended up with about six different variants of
\footnote music functions, all doing the same but with slightly
different input and different names. Using optional arguments instead
meant streamlining the syntax into something the user can actually
remember.
Of course, we have to first agree that the problem to be solved is
parser complexity, and not lack of conciseness / excess of red tape.
I am simmering down parser complexity in between. This is ongoing work,
and it improved maintainability again. Maintainability is not in high
regard in the LilyPond community: if I ask people to document their
code, the typical reaction is that I get ignored, or that they tell me I
should create an issue in the tracker for every line I want commented,
or that I should submit a patch for review myself.
For my own code, I am not fond of stuff that is hard to maintain, and
the parser has, in its current state, potential for more unification and
simplification. I have probably sometimes erred on the side of backward
compatibility in the past, but much of it _is_ reachable at moderate
cost after a few iterations.
Over the years, we worked very hard to cut as much syntactical red
tape as necessary. This has left us with a parser that is hard to
understand.
And an input format that is not really suitable for inter-application
communication. Like PostScript, LilyPond is essentially a write-only
language, with the sole reliable reader being a full interpreter.
All of the examples above look jarring to my eye; btw.
Yup. And that's the exact reason we are willing to pay the price.
The basic
expression in lilypond looks like
c4 d4
rather than
c4 , d4
ie. elements of the language have no explicit separators. That implies
that we have to do lots of lookahead and precedence twiddling to
determine how to group parts of the language.
for skipping requires evaluating the music expression first before
letting the parser change state or pushing back a synthetic token which,
again, is only possible when there is no lookahead token yet.
This is stalling things like
URL:http://code.google.com/p/lilypond/issues/detail?id=2067 and leads
to behavior surprising to users.
Why should this be in a music function at all? If the user knows
enough scheme to understand that port means file, he would be expert
enough to write the expression in Scheme anyway?
You expect the user to write the whole music expression to print in
Scheme as well?
Something like
Re: preliminary GLISS discussions
David Kastrup d...@gnu.org writes:
Han-Wen Nienhuys hanw...@gmail.com writes:
On Thu, Aug 30, 2012 at 9:21 AM, David Kastrup d...@gnu.org wrote:
Is there a complete proposal of what is on the drawing board? Barring
that, is there a list of (perceived) problems in the current
syntax/parser?
The possible values for music following a skipped optional argument are
constrained to music parseable without lookahead because the decision
I had to let this sink in for a bit, since I had completely missed
that a patch doing optional music arguments had went in. Had I noticed
in time, I probably would have complained (and we might have ended up
in a flamewar).
It was a matter of what's good for the goose, should be good for the
gander. The existing hardwired LilyPond syntax used a variety of
optional arguments (partly skipped explicitly using \default, partly
left out like with \relative { c' }). Bringing the preexisting syntax
within the scope of music functions meant making Scheme programmers
stop being second-class citizens who have to take what they are fed.
As one example for an analogous use of optional arguments, consider
\tweak Accidental #'color #red cis4
\tweak has always been a music function. Being able to use a syntax
fairly analogous to that of \override makes things simple and
straightforward for the user. You don't want to write \default in place
of Accidental for every use without a grob qualification.
And you don't want to have him remember different function names for
each argument list variation.
Of course this means that _compiling_ LilyPond into Scheme rather than
interpreting it is not feasible when using #{ ... #} inside of
functions. If this becomes really important one day, one can use trace
compiling techniques: one compiles a version corresponding to the
_current_ argument values while keeping track of the preconditions on
the values corresponding to every syntactical decision taken. As long
as the preconditions for the taken syntactical decisions are met on the
next call, one uses the precompiled Scheme equivalent of the passage in
LilyPond syntax. Otherwise, one repeats the process by calling the
parser on the LilyPond version again.
It is likely that 99% of all #{ ... #} constructs are not syntactically
polymorphic, at least not intentionally so, so this technique should
usually be low-overhead. On the other hand, the LilyPond parser is not
exactly inefficient, either.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Jan Nieuwenhuizen jann...@gnu.org writes:
David Kastrup writes:
Ah, I was unclear. Right. LilyPond stands out /together/ with Perl in
unreadability; these are the only two languages I know that can have
functions look like statements.
Hm? Scheme, C, C++, awk, Lua...
C Perl Ly
postfix: foo.bar foo-bar a\staccato
function: foo.baz () foo-baz \relative a
Consider this valid .ly file
\new Staff {
\relative \ff a \staccato b \pp \parenthesize \skip 1
}
Well, the optional argument for \relative is something we should have
sent to heck years ago. f would have been a nicer default value anyway
(it makes the first element of \relative's argument be in absolute
pitch).
% INVALID, can you guess why?
%\new Staff {
% \relative a \ff \staccato b \pp \parenthesize \skip 1
%}
Sure. \ff \staccato are events without a place to go. \relative a \ff
actually is accepted because LilyPond does not double-check that after
identifying a music function to be in non-post-event syntax that it
does, indeed, after calling return a non-post-event. I think I will
likely implement a warning for that soonish. Or get the syntax change
done where music functions are _first_ parsed, _then_ interpreted as
postevent or otherwise.
\new Staff {
\relative c \ff a \staccato b \pp \parenthesize \skip 1
}
\relative without delimited second argument is just imprudent. The
computer language that can prohibit imprudency has not yet been
invented.
\new Staff {
\relative c \parenthesize a \staccato b \pp \parenthesize \skip 1
}
Same here.
\new Staff {
\relative c-\ff a \staccato b \pp \parenthesize \skip 1
}
Interesting case. Should be equivalent to \relative c \ff since as a
function argument, \ff and -\ff are both valid and identical music
expressions.
\new Staff {
\relative c c \ff a \staccato b \pp \parenthesize \skip 1
}
Again, use braces around c \ff.
quite hard to guess what will be produced. For example, why is the
third stave's a one octave lower?
Because it is not part of \relative.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Graham Percival gra...@percival-music.ca writes:
On Fri, Aug 31, 2012 at 11:11:28PM -0300, Han-Wen Nienhuys wrote:
I have become convinced that optional, unnamed arguments are not a
happy design decision, in any language. In Lily it's particularly
problematic, since we don't group function parameters.
I agree; it's a mess. Let's examine David's most hated example:
\version 2.15.0
{
\tempo 4 = 60
c1 c
\tempo 4. = 60 ~ 72
c1 c
\tempo Andante
c1 c
\tempo Allegro 4 = 120
c1 c
\tempo Allegro 4 = 120 ~ 144
c1 c
\tempo \markup{ Presto } 4. = 172 ~ 188
c1 c
}
What are the options here?
1) use explicit delimiters for function arguments
(i.e. \tempo {...})
2) add a non-argument like \default for all parameters which are
not needed
3) define different function names, i.e. \tempoNumber,
\tempoNumberRange, \tempoText, \tempoTextNumber...
NB: I am not suggesting that all or any of those ideas are good;
I'm just trying to list the options that I can think of.
It is reasonably easy to state this will have to go. However, I have
not so far attempted a replacement since I am still fuzzy on
assignments. Basically I want to have the equivalent of procedures with
setters for LilyPond at one point of time, being able to write things
like
(set! (array-ref violin 1) #{ ... #})
as
\violin 2 = ...
In order _not_ to have _syntactical_ categories like vector of music
hardwired into the syntax, this requires parsing of functions
essentially independent from the type they end up having: first a
function needs to get evaluated, and its type is determined by the type
ending up as its evaluation.
So there are several steps I need to get done first before it makes
sense for _me_ to take a survey of what kinds of \tempo syntax make
sense and what not. 172 ~ 188 is an abomination anyway. It would be
reasonably straightforward to accept a pair here, like #(172 . 188) or
172/188 which is equivalent.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Graham Percival gra...@percival-music.ca writes: On Sat, Sep 01, 2012 at 01:27:23PM +0200, David Kastrup wrote: 172 ~ 188 is an abomination anyway. It would be reasonably straightforward to accept a pair here, like #(172 . 188) or 172/188 which is equivalent. Straightforward from a programming perspective, but as far as printed music is concerned, a tempo range doesn't look anything like 172/188. It doesn't look like 172 ~ 188 either. Hmm, I wonder if we could steal a page from LaTeX and use 172 -- 188 to indicate a range? of course then we might run into problems with people writing 172 - 188 so it's not a foolproof solution. I don't think it makes sense to go overboard on syntax just because of \tempo. Just split this into two commands, one for the markup (in which case the musician can use any range indication he likes or text like Allegro) and one for setting the actual speed (where a range is not needed anyway). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes: I think a musician is red herring word. There are many people that think that Lily is too complex for musicians already, and many others (including me) that think that musicians are smart people and can learn rules, especially if they are simple and consistent. With composers like Schönberg, you'll have a hard time making the LilyPond score look scarier than the output. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes:
On Sat, Sep 1, 2012 at 11:42 AM, Han-Wen Nienhuys hanw...@gmail.com wrote:
\tempo \markup{ Presto } 4. = 172 ~ 188
c1 c
}
While this might be a mess for the parser to sort out it is perfectly
understandable for a musician trying to write his/her music.
This is also the danger of having broad discussions over syntax.
Everyone and their dog has an opinion of what syntax should look like,
because an opinion is easy to form about
172 -- 178 vs.
172 ~ 178 vs.
{ \tempo 4=72 \tempoMarkup \markup { \noteMarkup #4 = 172 - 178 } }
and whether to allow
\relative { c d }
as a short hand for
\relative c' { c d }
on the basis of how intuitive it looks.
It should be short for \relative f { c d } actually:
\relative f { c } - c
\relative f { d } - d
\relative f { e } - e
\relative f { f } - f
\relative f { g } - g
\relative f { a } - a
\relative f { b } - b
\relative f { c' } - c'
\relative c' { c } - c'
\relative c' { d } - d'
\relative c' { e } - e'
\relative c' { f } - f'
\relative c' { g } - g
\relative c' { a } - a
\relative c' { b } - b
\relative c' { c' } - c''
Now which seems more natural as a default value? Not having to spell
out the f has the advantage of not having to think about what
peculiarity it is that favors f for this application.
In the end, each syntax is a compromise between what you allow for
expressivity, and how much you disallow to stop the user from shooting
himself in the foot. If you decide to reinvent the syntax, you are
only moving about the compromise, closing off one nest of rats in
exchange for opening a can of worms.
Yup. For a single command, \tempo overstresses the parser's hospitality
in my opinion.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes:
On Sat, Sep 1, 2012 at 8:27 AM, David Kastrup d...@gnu.org wrote:
It is reasonably easy to state this will have to go. However, I have
not so far attempted a replacement since I am still fuzzy on
assignments. Basically I want to have the equivalent of procedures with
setters for LilyPond at one point of time, being able to write things
like
(set! (array-ref violin 1) #{ ... #})
as
\violin 2 = ...
In order _not_ to have _syntactical_ categories like vector of music
hardwired into the syntax, this requires parsing of functions
Again, I would argue that people that know what a vector is, and how
to use it will be better served by writing scheme directly.
You can also argue that people that know what a duration is, and how to
use it will be better served by writing Scheme directly. Because a
duration is complex enough in Scheme already.
Or that people who know what a music list is should be writing it in
Scheme. Just because something can be represented in Scheme does not
mean that a mapping to LilyPond does not make sense.
Vectors don't make sense unless you give a mechanism to map/iterate
over them, ie something along the lines of
(make-parallel-music (vector-list
(map (lambda (x) (add-new-context Staff x)) violin)))
It would be easy enough to let $@ work on arbitrary sequences, not just
lists. You can already write things like
$@(map ...)
How many people are asking for \violin2 all the time?
essentially independent from the type they end up having: first a
function needs to get evaluated, and its type is determined by the
type ending up as its evaluation.
The type / evaluation dichotomy was something I have struggled with as
well. It might be feasible to construct a real type system inside
lilypond, but at the same time, we want to evaluate scheme function
inline as we parse them. Those two are difficult to reconcile.
I am making good progress on that, actually.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes: On Sat, Sep 1, 2012 at 5:37 AM, David Kastrup d...@gnu.org wrote: As one example for an analogous use of optional arguments, consider \tweak Accidental #'color #red cis4 \tweak has always been a music function. Being able to use a syntax fairly analogous to that of \override makes things simple and straightforward for the user. You don't want to write \default in place of Accidental for every use without a grob qualification. And you don't want to have him remember different function names for each argument list variation. Here is another premise that hasn't been agreed on explicitly. I would nowadays hold that it is actually better to have different function names, and have the user be explicit about what he is doing. But he is doing the same thing in each case. It will either mean he has to remember different names for the same thing, or we use some systematic combination of function name and argument types, requiring the user to do name-mangling. The discussion about syntax changes is not going to work unless we know in what direction we want to go. I am mostly evading that question by staying where we are, but placing wheels under the furniture, allowing us to redecorate when desired. Namely by asking the question what kind of tools would make it possible to create more of the same. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Graham Percival gra...@percival-music.ca writes: 1. declare the 2.16.0 syntax absolutely frozen (possibly with the exception of property names and scheme). Reject absolutely all patches to lily/parser.yy That does not make sense as long as we don't have a reasonably coherent starting point for freezing. 2. have a serious and respectful discussion on lilypond-devel about these compromises and whether we think it is appropriate to select a different compromise for some portion(s) of the syntax given what we've seen from the past 15 years of LilyPond. 3. have a serious and respectful discussion on a different list, and when those discussions reach a firm proposal, bring that proposal to lilypond-devel for a serious and respectful discussion about the well-researched proposal. So far I don't feel that the discussion has been very fruitful. And it will not be fruitful in the near future. One reason is that I am basically the only one seriously working on the parser right now, and I am learning while I am working on it, both about the work flow for getting Bison where you want it, and about the complications. This is work that is really hard to do, but it can't be done except, basically, incrementally. Even though the end point is consistent in itself again. And it needs experimentation to find the next incremental step. It is nice to say one should first declare where one wants to be going and only start moving after having finished the plan. But it is not realistic. All in all, this is taking a direction that gives more power and flexibility to the user, while making LilyPond more programmable, and thus even less suitable as a general purpose music representation. But it never _was_ all that suitable. It has almost always been complex to a degree that the only reliable LilyPond parser has been LilyPond itself. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes: On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup d...@gnu.org wrote: Vectors don't make sense unless you give a mechanism to map/iterate over them, ie something along the lines of (make-parallel-music (vector-list (map (lambda (x) (add-new-context Staff x)) violin))) It would be easy enough to let $@ work on arbitrary sequences, not just lists. You can already write things like $@(map ...) How many people are asking for \violin2 all the time? How many people of these are asking for a O(1) indexed access container? I think most people just want to write 2 instead of Two. I don't see how a person asking for \violin2 is asking for arrays. Most compositions don't have more than 2 violin voices anyway. I am actually supportive of allowing digits in identifiers, it has irked me for years that we could not get it to work. It is easy enough to get to work. It just comes at a cost. I vaguely recall you implemented this in 2.16 already, but I guess I am mistaken? You are. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes: it seems that we are still inventing our syntactically complex programming language, which ironically is implemented on top of GUILE Scheme. There is no irony involved. Scheme's syntax is computer-friendly, LilyPond's syntax is user-friendly. If they did not serve complementary purposes, we would not need both. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Graham Percival gra...@percival-music.ca writes:
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
as .clef or .times.
.version 2.16.0
.score {
/new Staff {
.clef bass
.times 3/4
c4 /parenthesize d\p g .bar |.
}
}
It's obviously not a fully-thought-through idea, but the whole
point of brainstorming is to list not-fully-thought-through ideas.
It adds no new functionality and makes it harder to write and read
things. How should LilyPond behave if you get your slashes wrong?
If one does not add new functionality anyway, one can pretty well make
things readable using spaces where appropriate.
Frankly, the current syntax discussions are leading nowhere.
Brainstorming is fine, but pretty useless if there is no target or topic
other than let's make things different.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes:
On Sat, Sep 1, 2012 at 12:04 PM, David Kastrup d...@gnu.org wrote:
You can also argue that people that know what a duration is, and how to
use it will be better served by writing Scheme directly. Because a
duration is complex enough in Scheme already.
The whole idea of integrating pure Scheme expressions, ie. #(+1 2),
into LilyPond was to avoid the complexity of having to invent another
programming language.
Ah, but you did.
do = 1 - 3
\language italiano { do = 1 - 3 }
What does this do?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Graham Percival gra...@percival-music.ca writes: On Sat, Sep 01, 2012 at 09:18:17PM +0200, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: Continuing to brainstorm on the problem of it not being obvious to which note a particular \command refers to, what if we used: \postfix: c2 d\p is unchanged /prefix: for music functions like c2 /parenthesize d .neutral: for commands which aren't attached to notes, such as .clef or .times. It adds no new functionality and makes it harder to write and read things. How should LilyPond behave if you get your slashes wrong? Give an error? The new functionality is it becomes obvious whether a command applies to the note before or the note after. That's what whitespace is quite good for. Since we wouldn't have any definition for /p, writing that would produce an error. (each prefix character would have its own namespace) So LilyPond would pretend that it does not know what you are talking about, instead of saying I know this one, and this is the wrong place to put it. Frankly, the current syntax discussions are leading nowhere. Brainstorming is fine, but pretty useless if there is no target or topic other than let's make things different. The target is let's make it easier to learn/write/read .ly files. .I -don't -see that +affixing .words .with .various .letters +indicating .particular .categories -will +help -understanding .much. The meta-target is after spending 5 years very publicly telling people *not* to talk about changing the syntax because we would do so 'in a year or two', I think I should encourage such discussions.. I mean, people trusted me when I said that there would be a time for discussing syntax changes. It was advertized on our help us page for something like 3 years until Janek commented it out in 884194 on 2012-02-14 because noone knows when GLISS will happen. If I didn't fight to give people an *opportunity* to have a meaningful *discussion* about syntax changes before we stabilize things, I would be abusing that trust. Well, the music function work has removed a lot of pressure of the I want my favorite construct xxx in the grammar kind since there are quite a number of things people can put in themselves if they want to. Yes, the process of making music functions more versatile was quite undemocratic. But it was not as much that I was sole decision-maker, but rather that my skills and areas of interest were shaping the work I was doing, with a focus of making currently existing constructs reimplementable in Scheme. The direction that LilyPond's parser is taking is increasingly supporting _constructs_ as contrasted to _elements_. So there is much more inclination nowadays to ask oneself the question how can I express this with existing tools? rather than how can I fit this into the parser as well?. That does not mean that everything one had wished for can now become a reality, but often the old wishes are so much more close to what is already possible that the smaller differences are not much of a bother. I'm quite open to trying to find a way to structure these discussions so that people who are interested can participate, yet people who aren't interested don't need to worry because they'll get an opportunity to shoot down bad proposals before they're accepted. But we've barely *started* having a discussion about changes, so I don't think that we can claim that they're going nowhere. It is not as much bad proposals rather than arbitrary ones that I am worried about. Stuff that is no substantial improvement or deterioration, yet causes a lot of energy and possible incompatibilities. We are not starting from scratch but an existing language, and incompatibilities should not be gratuitous. At Waltrop, you only heard about one quarter of the ideas that Janek had. I've got about half of the number of ideas that he had. And that's just two people; who knows how many ideas our users have. Or what about people like Francisco -- IIRC he's been teaching lilypond to composition students for the past 5 years. How many people per class... maybe 30? So he might have taught 150 students how to use lilypond? I'm sure that he has some thoughts about what his students found difficult to understand. Of course many of our ideas will not be good. That's fine! That's how creative thinking works! So let's create a place -- either on this list, or a different list -- where people can talk about their ideas, point out flaws and make suggestions, look for common themes, etc., and see if there's anything worth adopting. Locking people away in a syntax discussion list, then ignoring them or having to deal with the consequences does not sound like a strategy fair to either those interested in changes, nor to those not interested but affected by such changes. -- David Kastrup ___ lilypond-devel mailing list
Re: slides-in-tablature.ly snippets: string numbers of hided notes are visible
pls p.l.schm...@gmx.de writes:
There must have been a change in default with regards to the
visibility of string numbers between 2.15.20 and the current
version. In 2.15.20 it was still possible to add string numbers to
notes (e.g. c'4\4) without them showing up in the score.
But they showed up when writing c'4\4, so this was more a convenient
bug than anything else.
This was very handy in order to automatically specify the appropriate
fret on the right string in tablature. One could decide whether to
output individual string numbers via c'\44 or not to engrave them
via c'4\4.
And what would you do when _wanting_ a chord with more than a single
note but no string numbers?
Now it seems that this behavior can only be achieved by constantly
overriding the string number stencil...
Not that bad:
n=#(define-event-function (parser location e) (ly:event?)
#{ \tweak #'stencil ##f $e #})
{ c'\4 c'\n\4 }
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Janek Warchoł janek.lilyp...@gmail.com writes:
On Sat, Sep 1, 2012 at 6:25 PM, Graham Percival
gra...@percival-music.ca wrote:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes
there would be confusion with augmentation dots, and possibly with
rational numbers.
On Sat, Sep 1, 2012 at 6:37 PM, Werner LEMBERG w...@gnu.org wrote:
What about this: A command used as a prefix needs to enclose its
argument in braces (or whatever). Commands like \relative already
look similar.
postfix: c2 d\p
prefix: c2 \parenthesize { d }
Uh, oh, please forget this. It would be great if it could be that
simple :-/
Actually, why not using this for music functions? I.e. \parenthesize
{ d } and d-\parenthesize.
d-\parenthesize-\p is supposed to do what then?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Jan Nieuwenhuizen jann...@gnu.org writes:
Han-Wen Nienhuys writes:
I have become convinced that optional, unnamed arguments are not a
happy design decision, in any language. In Lily it's particularly
problematic, since we don't group function parameters.
If we start doing this, that would solve the several of the issues
raised.
What issues were raised?
It would move a bit away from the `lets remove all red tape' path that
we (I?) embarked on previously.
There are two commonly used ways of grouping function parameters,
instead of
\relative { a \parenthesize b c }
we could have something* like
(relative { a (parenthesize b) c })
relative ({a parenthesize (b) c})
I don't think there are easy ways to combine or drop ( and }, ie have
something like
{relative a b c}
foo = relative
{foo a b c}
Or the C-style equivalents.
Who do we think to be doing a favor with that?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Jan Nieuwenhuizen jann...@gnu.org writes: David Kastrup writes: Using LilyPond for reading LilyPond files (as opposed to parsers written in Python) has the advantage of being rather thorough, and the disadvantage to be tied into a single version (not all that helpful if you want to write something like convert-ly). Maybe the time has finally come to drop convert-ly and implement and fully supported conversions using LilyPond on music stream level. You still need a parser of the appropriate version at the front end. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Jan Nieuwenhuizen jann...@gnu.org writes: David Kastrup writes: Maybe the time has finally come to drop convert-ly and implement and fully supported conversions using LilyPond on music stream level. You still need a parser of the appropriate version at the front end. We have perfectly fine ly parsers of each available version available in executable form from lilypond.org. What we do not yet have, is a handy or integrated way of dumping the music tree with the original binary [read: a nice web service -- this could possibly be integrated with a mutopia revival, I'll be looking into this] reading the music tree with the current version and a perfect ly-dump function. Eg, I think we may want to preserve %-comments in the music tree, or other stuff the user does not want to lose? For an emergency conversion web service of an archive in case of convert-ly failure, a Scheme-written package diverting all required hooks like toplevel-book-handler, toplevel-bookpart-handler, toplevel-score-handler, toplevel-music-handler, toplevel-text-handler could likely be written. The meaning of spacing variables would need conversion, some overrides likely as well, context definitions and stuff would be a bit tricky to properly detect (but one could just start out with empty context/output defs and consider every change as relevant), but as an emergency measure, I consider the likelihood of getting at least something useful out for a majority of scores when run on the respective original version of LilyPond reasonably high. It would work at the music expression level, not at the stream event level: the latter has already lost too much information. All the input syntax/music function folderol would not be an issue since those have already done their work at the time of calling the handlers. Markup functions might be more tricky. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Jan Nieuwenhuizen jann...@gnu.org writes:
David Kastrup writes:
What issues were raised?
Janek and Graham raised the `what is a music function / let's make
everything postfix' issue.
That's rather vague as an issue description. Sort of the What is a
preposition / let's make everything a case issue converting modern
English into Protoindoeuropean. The answer try learning your grammar
before replacing it by something even more complex is sort of
inevitable.
Han-Wen raised the issue of [nameless] optional arguments.
instead of
\relative { a \parenthesize b c }
we could have something* like
(relative { a (parenthesize b) c })
relative ({a parenthesize (b) c})
I don't think there are easy ways to combine or drop ( and }, ie have
something like
{relative a b c}
foo = relative
{foo a b c}
Or the C-style equivalents.
Who do we think to be doing a favor with that?
Well, that's the question. This is also a good chance to, ahum,
once and for all decide on leaving things as they are.
I repeat myself: as long as as they are is not obeying a documented
and coherent definition, that's rather pointless as well.
The conservative approach is rather moving towards a consistent state
from the current starting point in the least damaging manner.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Keith OHara k-ohara5...@oco.net writes: Janek Warchoł janek.lilypond at gmail.com writes: On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup dak at gnu.org wrote: Graham Percival graham at percival-music.ca writes: So far I don't feel that the discussion has been very fruitful. And it will not be fruitful in the near future. One reason is that I am basically the only one seriously working on the parser right now, and I am learning while I am working on it, both about the work flow for getting Bison where you want it, and about the complications. This is work that is really hard to do, but it can't be done except, basically, incrementally. For what it's worth, i'm ok with this discussion (and similar ones) happening on devel, as long as we won't loose track of concrete proposals (when they will appear, ofc.). I posted a patch for the numbers-in-identifiers enhancement http://code.google.com/p/lilypond/issues/detail?id=1670 It might help a little as a concrete example, showing the challenges of supporting LilyPond's very lenient syntax. (I can't really tell for sure, but I think maybe David likes the patch.) Just shows what an abysmal communicator I am. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] verbifying music functions
Keith OHara k-ohara5...@oco.net writes: Graham Percival graham at percival-music.ca writes: Let's have a look at verbifying music functions. [and special-cases that look just like music functions to the user] Most pre-fix functions do seem to be verbs expressing what we want LilyPond to do to the following music. The exceptions appoggiatura = \addAppoggiatura ? not nice clef are nouns because they are themselves the notation. The implementation is that \appogiatura transforms the following music into an appogiatura, but we think of the appogiatura as the main concept, and the pitches describing the appogiatura. Similarly the \clef treble_8 The ones with obvious changes to verbs, really should be verbs to help us remember that they do something to the following music balloonText = \addBalloonText I think that those commands basically retaining their last argument with extras could be \withBalloon \withFootnote \withTag \withTweak ... but I am not particularly convinced that this really makes things easier for people. I would go so far as bookOutputName = setBookOutputName Actually, I have code allowing \bookOutputName = ... to be used (\bookOutputName itself then referencing it). It just does not make all that much sense without a few other changes in music functions. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Han-Wen Nienhuys hanw...@gmail.com writes: On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival gra...@percival-music.ca wrote: The meta-target is after spending 5 years very publicly telling people *not* to talk about changing the syntax because we would do so 'in a year or two', I think I should encourage such discussions.. I mean, people trusted me when I said that there I have been trying for years on end to dissuade anyone from discussing or proposing syntax changes. Well, I am proposing syntax changes on a regular schedule... Most of them don't affect the bulk of existing LilyPond files, while often changing the set of valid files significantly. It is often in the wait, you mean _this_ was valid LilyPond code before? area. Look how successful I was. Whatever you have been saying in the past is irrelevant. Hardly. We have a continuity of developers and expectations, and that is what Graham has to work with. I predict that a lot of discussions will be had, and we will end up with virtually no changes. I guess that such is life. Of course many of our ideas will not be good. That's fine! That's how creative thinking works! No; syntax discussions without understanding how the lilypond parser works is just blowing around hot air and discussing bike shed colors. The LilyPond parser toolkit is rather powerful, and one can do a lot with it. Partly by tricking around and doing some things manually when they are definitely worth doing. Most of the proposals are a bad idea without actually having to look at implementability because they introduce ambiguities that are hard to resolve not just in LilyPond's parser (which can be fiddled to be able to do a lot of fine distinctions), but generally in the grammar. Usually when it is hard to teach LilyPond's parser fine distinctions, it means that it is hard teaching its users the fine distinctions as well, and hard to teach convert-ly the fine distinctions, and hard to teach programs writing and reading LilyPond the fine distinctions. And many proposals are of the kind one can't even resolve with fine distinctions since they are inherently contradictory or ambiguous. The problem is not that the parser would not warrant some changes. The problem is that the discussion tends to focus on lines leading nowhere for various reasons, and that causes a state of panic for those actually working on the parser, and frustration for those who feel that their proposals are not taken seriously by those in power, namely actually working with and on the parser code. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gerrit - does it allow writing commits using a web interface?
Janek Warchoł janek.lilyp...@gmail.com writes: Hi John, i remember that you are investigating whether we could be using Gerrit for Lily work. I may've asked this question already, but i don't remember whether there was a definitive answer: does gerrit have a web interface that allows to create new commits using only a web browser? I've skimmed over http://qt-project.org/wiki/Gerrit-Introduction but didn't find any answer. The reason i'm so concerned about this is simple: it would enable hordes of LilyPond users (;-)) to participate in Lily development. The following situation happened to me several times: a user had a problem, i've explained how to fix it (or simply sent a link to appropriate section in manuals), and i asked how could we improve the manuals so that you had found this information easier/understood it better?. Unfortunately, the responses are usually too vague to be turned to a patch on the spot, and i don't have time to think about them myself (and it doesn't make sense to ask the user to install Lilydev and learn how to make a patch just for this). With a web interface, this would become massively simpler. Also, Graham's catchphrase patches appreciated would become much more powerful :) Frightening rather. I don't spend enough time defending LilyPond against awful patches as it is. An automated system should likely reject any patch not containing at least 25% of comment lines in code areas (would be nice if this was the case for every submission). Our quality of code is terrible, and part of the reason is that submitters just can't be bothered being interested in producing maintainable code. Part of the reason is that the existing code base is not really a shining example. There is a lot of code that works because of fine points and underlying designs that are not documented, and so this code is useless as a template for how to write code that does not explode around everyone's ears eventually. It is also a timebomb for maintenance since changes might violate underlying assumptions. And that is just talking about code that actually works for good reasons. Quite a bit of code works since it has been prodded into not failing under those circumstances that tend to be tested. It is easy to make it easier to meddle with LilyPond code. The low number of contributors is not due to our toolchains. It is because few people are comfortable poking around in the dark. And for good reason. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes: On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen jann...@gnu.org wrote: David Kastrup writes: Maybe the time has finally come to drop convert-ly and implement and fully supported conversions using LilyPond on music stream level. You still need a parser of the appropriate version at the front end. We have perfectly fine ly parsers of each available version available in executable form from lilypond.org. What we do not yet have, is a handy or integrated way of dumping the music tree with the original binary [read: a nice web service -- this could possibly be integrated with a mutopia revival, I'll be looking into this] reading the music tree with the current version and a perfect ly-dump function. Eg, I think we may want to preserve %-comments in the music tree, or other stuff the user does not want to lose? The tree is not what people want, though? The tree has no information about identifier subsitutions, and you only get the output of each music function application. It is not the preferred form for modification. Unless its distinguishing feature is that it works at all and you lack the expertise for modifying the original source code in a manner making it work under newer LilyPond versions. For the users of things like Mutopia, more often than not the desire is not to see interesting source code, but rather the ability to tweak paper dimensions and scale and transposition, fix single typos, and rearrange material. Not having to cut a \relative call into several parts for which you have to hand-recalculate the starting pitch might actually be an advantage. For the majority of people interested in scores, LilyPond is gobbledygook. They still want to pull scores from it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Werner LEMBERG w...@gnu.org writes: Rather than proposing something by way of example, I would like to see all proposals in the form of a parser patch that does not introduce extra shift/reduce or reduce/reduce conflicts, and maintains general backward compatibility. If a proposer manages to get that far, I promise I will take a serious look at it. You are exaggerating, aren't you? With this prerequisite, very useful stuff like `q' would have never been implemented. It took David a long time to generalize it, Uh, no. Not generalize it. _Fix_ it. The implementation was totally broken and incompatible with LilyPond's normal way of operating (namely, it did not survive copying of music, and LilyPond copies music in a lot of situations). It was a bad hack on top of the parser, based on assumptions that were invalid. It became only possible to approach having it work sensibly when issue 2240 was implemented for different reasons, because before 2240 there was not even a distinction between chords and single notes in the music data structure, and without that distinction, q simply _could_ not work reliably. but IMHO it was worth the trouble. In my opinion, it wasn't. Just because I found a way to clean up after people that did not worry about breaking things they don't understand in return for a modicum of convenience does not mean that this was a good idea to start with. We are just now starting to see the tip of the iceberg of users having to deal with issue 2240. Bringing LilyPond input into closer relation with the resulting music expressions (without changing the resulting stream events) was important for other reasons, most importantly for being able to work with music functions in the context of chord elements. That it brought it into reach to fix the totally broken q was a side-effect (or rather, its main-effect, but in an area of less importance) that would, on its own, not have warranted the compatibility drawbacks of issue 2240. Perhaps we should start differently: Instead of making ad-hoc syntax suggestions, let's collect experienced user reports about the most annoying LilyPond syntax issues. The stress lies on *user*, not developer. Then parser experts can have a look whether changes are possible and useful. A collection of issues rather than a collection of purported remedies might indeed make more sense. As an example, take I find the need to write something like \violin2. One remedy is to allow numbers into identifiers. This can take a large variety of forms. Keith's patch is basically a sketch of very specific form, with advantages and disadvantages not all inherently tied with the issue as such. The general issue still has to answer the question What with \skip4? Keith's answer to this particular issue is only permitted inside of music, and his answer to what about top level which currently _is_ music is let's make it almost, but not quite, non-music. And consequently his implementation of this concept requires meddling with both lexer and parser and consistency of lexical units. The details of this meddling could be improved, but the basic need remains. So my approach to that issue in general is different, and in particular to the question what with \skip4 is what with it?. I am for keeping \skip4 equivalent to \skip 4 and, consequently, for keeping \violin2 equivalent to \violin 2 and, by the way, equivalent to \violin #(1+1) as well. Namely make \violin aware that it requires a number to form a reference. This does not require meddling with the lexer, but it certainly requires meddling with the parser. And, of course, it opens another can of worms, and it will take quite a bit of work to smoothen the edges of this can since it is quite a bigger can. And there is further work pending before it becomes even feasible opening it. Which sounds a lot like q actually. In generally, it is a good idea to move LilyPond in a direction where it becomes feasible to open a number of cans of worms: it usually means a robust and flexible direction. But that does not mean that every can coming into reach then actually is worth opening, and quite a few are exclusive, meaning that their opening locks down the possibilities of future changes again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uncommented code in LilyPond
of this stuff remained astonishingly clear and well-designed when looking at it decades after writing it. But nobody except myself is going to maintain it, and what you don't see are wastepaper baskets full of drafts and diagrams. They are inherent in the code, and that _does_ help in understanding the code because it is _not_ just written from scratch, but an actual implementation of a long-planned coherent design. And the source code had to be stored on magnetic tape at 2400 bps, and it had to fit in something like 50kB at the most. We don't have those kind of restrictions any more. The design, or at least its constraints and how and why the current code meets them, belong in the source code. Not implicitly, but explicitly. Code is written once, and in any healthy project, read multiple times. So it is the task of the writer to make efficient use of the readers' resources. When reading is faster than figuring things out, and this is pretty much _always_ the case where the relations with other code pieces and the choice of particular non-trivial data structures are concerned, a comment saves even a single reader more time than it costs the writer. You probably know the joke about the experimental physicist approaching the university dean for more money. And the dean says something like Money, money, money. Why can't you take a leaf from the mathematicians? We just provide them with pencil, paper, and a wastebasket, and that's all they need. And the philosophers don't even need a wastebasket... Regarding the expensive storage area for comments, some of the old code might have been written by mathematicians. Which is bad. What is worse if you figure oh, this makes all sense, so I'll write without comments as well and make equal sense because you never got to see the wastebasket. Han-Wen and Jan explained the code to each other until it made sense. Too bad they did not write the explanations down. By writing comments, you can at least explain the code to yourself. If you find that hampers your flow significantly, it is likely that you are not writing code easily explained to anybody. Including the computer. I may be a silly old fool, but I've grown old enough to gain the arrogance to consider code for which I don't understand its purpose after reasonable consideration is bad, because I am far enough to the right of the bell curve on understanding computers and programs that code that is beyond me is for all reasonable purposes beyond meaningful maintenance, possibly even by its own author but most certainly by an average programmer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Werner LEMBERG w...@gnu.org writes: but IMHO it was worth the trouble. In my opinion, it wasn't. Thus spoke the developer. From a user's point of view who has to write a lot of piano music, `q' is *really* valuable. In a score editor. Like Emacs' LilyPond-mode. Or Frescobaldi. Nobody says that you should not be able to make use of shortcuts, but that does not mean that the LilyPond language is the right place for providing them. Editing shortcuts have a nice place in editors. q is one of those features that make LilyPond unfeasible as a storage format for music. Users like to save keystrokes, and they bemoan the demise of Mutopia, and the rise of MusicXML over LilyPond as a music presentation format. Nobody wants to see the connections. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Jan Nieuwenhuizen jann...@gnu.org writes: David Kastrup writes: Users like to save keystrokes, and they bemoan the demise of Mutopia, and the rise of MusicXML over LilyPond as a music presentation format. Nobody wants to see the connections. I'm glad you do. It's not that it helps much with the underlying problem. LilyPond is designed to be friendly to humans rather than computers. The mere existence of a full-scale general-purpose extension language is a killer criterion for music presentation in a computer-accessible way. Probably the best we can hope for is for LilyPond becoming the workhorse of music publishing and printing while the LilyPond language itself becomes a well-pampered side effect, similar to the role Ghostscript has in text publishing and printing: nobody(TM) actually uses PostScript anymore(TM). Of course, the roles are not entirely comparable since the PDF format as well as PostScript itself are well-defined and correspond to one _particular_ placement of ink on paper, while this is not the case for either MusicXML or LilyPond input. Regarding the processing of symbolic XML input, TeX/LaTeX also has some side role: nobody(TM) actually uses TeX/LaTeX anymore(TM), but it is still secretly or openly being used in the XML workflows of publishers like URL:http://river-valley.com/. In the medium time range, keeping something like Mutopia updated from bitrot might be achievable using intelligent crowd sourcing, but crowd sourcing always implies limits/costs in quality, coverage, reliability. That's why I suggested the investigation of truly supporting full future compatibility, using [an old] lilypond for parsing and [the current] for dumping .ly. \displayLilyMusic has been available for quite some time, and writing an extended version of it running under 2.10+ would be feasible as long as the primitives for getting at the required information are available. But the 2.10 corpus is finite, so there is no point in investing more work for automatic conversion of it than a manual conversion would cost. The most important consideration is to arrive at processes that will continue to work as use of LilyPond expands. Namely our business model should be able to deal with the possibility of success. Until we can guarantee that .ly will not bitrot (or even better: backwards supporting v2.14, v2.12,...), noone in her right mind will want to use LilyPond for storing large music libraries. That's a big loss for everyone, as musixcml does not preserve printability Neither does LilyPond, and it won't while we improve its capacities of placing things where they belong. and arguably also not full musical meaning/content. Neither does LilyPond. So one consideration for future development is to provide the means to extend LilyPond regarding content. That means, if we want to implement a feature, we have to tell LilyPond how to put this into music, how to get it from music back to LilyPond source, out to MusicXML, out to Midi, and out to paper. Without needing to write 15 different files in 10 directories and changing half a dozen existing files. There is currently no solution for preserving content as well as fine engraving, at least not with a relation between the two. Providing that would be a major win. Still a long road ahead. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Graham Percival gra...@percival-music.ca writes:
On Mon, Sep 03, 2012 at 02:20:43AM -0300, Han-Wen Nienhuys wrote:
To me, a Grand Input Syntax fixing of LilyPond, would amount to
creating a syntax that strictly separates parsing and interpretation.
This implies not only rethinking a lot of syntax, but also it means
letting go of some of the flexibility and conciseness of the current
format.
Ok, consider one single fix. Change:
{ \[ c'2 d' \] }
into:
{ c'2 \[ d' \] }
The old enclosing method of spanners (i.e. beams and slurs in
lilypond 1.x) is almost completely deprecated now. Why not take
the next step and fix ligatures as well? That would make the
syntax more consistent.
Sounds good to me. The disconcerting thing is that I don't see a good
convert-ly rule on the horizon: we should have done this long ago,
together with the rest. Let me take a look at the parser...
Looks like it would be simple to do, and likely one should also include
\~ (PesOrFlexaEvent).
I don't know the respective input modes and terminology: will there
always be a note to attach all those to?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uncommented code in LilyPond
m...@mikesolomon.org m...@mikesolomon.org writes: My code tends to be rather sparsely commented (if at all) because, as you state above, there is an internal logic to LilyPond created by the original authors that is uncommented but consistent, and once one understands that, one's work fits into that logic. But you are not one of the original authors and so your code has a different style and logic, and the fittings are differently and worth mentioning. Well, if we switch off hero worship for a moment, it's not like I don't want to hit Han-Wen and Jan over with a comment-eliciting clue bat as well. They might cite the excuse that they did not consider it possible that LilyPond survived beyond their active call of duty, but that excuse has grown old by now. We probably need a redocumentation project where every developer is assigned one source file in a language he is supposed to understand and is left with the task of leaving it in a documented state where he feels comfortable saying that he knows how it fits together with other files, what LilyPond language constructs will trigger its use under what circumstances, what choices were taken in the code, and that he is confident that the next one reading this file will, by virtue of its comments, be in the same position within half an hour. If he has questions, he will have the right to ask them from people that (short of code reformatting) git gui blame declares the responsible party, as long as they are still alive. In my book, this takes priority over any new work they might want to be doing instead. Answering questions does not take a lot of time. It would also make sense to remove the obligation to go through any kind of review for comment-only changes where the submitter _knows_ that his analysis of the intent is correct (knows rather than has convinved himself), either by an _exhaustive_ analysis, or by being or asking the original author. As for the valgrinding, a lot of my work in LilyPond is knowing what I want to do on thing X but not knowing how thing X is linked to other things in the code base. You don't find security problems by valgrinding, and things are similar for _potential_ memory problems. Either have the tendency to come into view when you don't really want them rather than when you politely invite them. For example, I'll know how grob X uses grobs to find its extents, but the reverse is much more difficult - knowing what grobs use grob X to find their extents. So it's true that when I start solving a problem it is often well beyond my understanding of how a single grob is interconnected to all other parts of LilyPond. If I let this stop me, I wouldn't have done any work on LilyPond. Sure. But at one point of time, we want the help and support and contributions from people that _will_ get stopped by this. And even we don't cared about those, we don't want to have the slowdown and concentration hit on those that _will_ eventually figure it out on their own. We don't want to _waste_ our human resources on inefficient processes, and figuring out what code does is most efficiently done by the person writing the code. If he has to do the job anyway, there is no point that the next person looking at the same files has to do the job again. I don't mind going through the code, file by file, and writing comments everywhere. I understand most of it and if you think that'd lead to better maintainability then it is worth it. I'll try to do 3-4 files a week. I think more of 6 people doing one randomly assigned file a month. It is ok if they feel they want to do more, but this will already cause quite a load of private mail on the original authors. And I definitely didn't mean to not respond to one of your suggestions - I forgot to get around to writing that comment you asked for as I was distracted by other things in the patch. Nor do I mean to ridicule you - the Strong Bad Tandy 400 comment was because I don't think there's a real efficiency tradeoff (I did some tests and in fact there isn't). I suppose Keith is hallucinating his results then. O(lg n) against O(1) for a single access is a trade off, in particular with a big constant factor. Searching for data when you could arrange for it to be at a certain place is a tradeoff. Maintaining a search data structure where things are entered and removed according to some complex scheme rather than by garbage collection (which is bad enough) is error-prone, with a non-zero probability of indefinite growth of the data structure. I do take your suggestions very much to heart, however, and am experimenting w/ a new way of going about it that uses only vectors and is much clearer. Thanks. LilyPond is complex enough without adding unneeded and uncommented complexity at every corner. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond
Re: [GLISS] differentiating pre/post/neutral commands
Graham Percival gra...@percival-music.ca writes: So far the discussion has gone according to my predictions. There's panic (and IMO overraction) from people who actually know the parser, which does not encourage open discussion of ideas. Why not hold the preliminary discussions on a separate list (to which parser experts are encouraged *not* to read), then only bring a proposal to -devel when it's ready? I mean, what possible downsides are there to this? Syntax discussions will not likely lead anywhere sensible without involving people actually having worked with parsers. Many proposals can be shot down with and what interpretation should we assign to x? kind of questions rather than I am the master of the parser, and you better will believe me that I'll never have x while I live. Now a question like and what interpretation should we assign to x? or an this would also imply y, and are you comfortable with that? is one of logic more than of parser design, but of course they are easier to come up with if you have been exposed to tripping over them a lot. Shooting bad ideas down fast means that one can cover more ground in the same amount of time before people run out of steam. It will be made abundantly clear to those on the lilypond-fluffy-syntax-discuss list that their ideas will not become code unless there's a good way for that to happen, and that nobody (especially not David) is responsible for turning them into code, and that technical concerns will trump any amount of niceness in examples, and any other disclaimers you want to add. I am afraid that this might rather demotivate people to work on proposals. If they take a week to write something up and it gets shot down basically in a minute, that's not exactly going to make them plunge with renewed vigor into the next week of writing up a proposal. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
ly and musicxml, some people worked on online/realtime score generation. The LilyPond community has some shared values, some opposing values, but an overall interest in the specific code base called lilypond. How can we work on that together, while respecting our individual differences? How can we encourage and keep ourselves motivated to improve LilyPond? Mutual trust and respect, communication of one's needs, working on the same or related overall goals. Policies have their place in that overall scheme, and also make some things easier to get done with. With regard to _designing_ the language of LilyPond, I think we are better off discussing and relating our goals, and seeing where this takes development. Yes, this requires trust, but policies can't replace that trust for all that they are worth. They are more a reminder for everybody where we want to be heading, and how we think we may arrive there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Trevor Daniels t.dani...@treda.co.uk writes: Graham Percival wrote Monday, September 03, 2012 1:00 PM That proposal became: http://lilypond.org/~graham/gop/gop_4.html I don't know where to go from here. I spend a lot of effort trying to organize such discussions, because I think that LilyPond is a community project. I think that we should encourage people to participate, but telling people ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC might discourage people from working. It did. No doubt. And I don't want to promote a setup which will essentially end up as exactly that when viewed honestly. Trying to empower non-programmers by handing them the decisions over what the programmers should be achieving is something I just don't see working out to the best interests of either. The only thing I can think of for evening out the balance is to make it easier for non-programmers themselves to bring LilyPond to do what they want it to be doing. That requires documentation, and it requires moving LilyPond in a direction where working with and on it with confidence becomes easier. This kind of empowerment has been the main theme of most of my work on music functions and Scheme/LilyPond interaction. It is, however, ongoing work, and I don't think I am doing anybody a favor by keeping it half-finished. I don't have good answers with regard to the questions what our policies should be focusing on and ruling on. And I am totally bad working according to instructions myself. But I definitely see that many people can be more productive by having good guidelines to work with. I am doing the best I can, but I don't really see how I can justly deny the underlying gist of the characterization ok, thanks for your work on XYZ, now get lost while the real developers talk about ABC. And I want to avoid creating organizational structures that will cause exactly that impression if I am trying to do serious work according to the best of my conscience. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Han-Wen Nienhuys hanw...@gmail.com writes:
On Mon, Sep 3, 2012 at 9:03 AM, David Kastrup d...@gnu.org wrote:
Graham Percival gra...@percival-music.ca writes:
On Mon, Sep 03, 2012 at 02:20:43AM -0300, Han-Wen Nienhuys wrote:
To me, a Grand Input Syntax fixing of LilyPond, would amount to
creating a syntax that strictly separates parsing and interpretation.
This implies not only rethinking a lot of syntax, but also it means
letting go of some of the flexibility and conciseness of the current
format.
Ok, consider one single fix. Change:
{ \[ c'2 d' \] }
into:
{ c'2 \[ d' \] }
The old enclosing method of spanners (i.e. beams and slurs in
lilypond 1.x) is almost completely deprecated now. Why not take
the next step and fix ligatures as well? That would make the
syntax more consistent.
Sounds good to me. The disconcerting thing is that I don't see a good
convert-ly rule on the horizon: we should have done this long ago,
together with the rest. Let me take a look at the parser...
Looks like it would be simple to do, and likely one should also include
\~ (PesOrFlexaEvent).
I don't know the respective input modes and terminology: will there
always be a note to attach all those to?
There are no specific input modes associated with ancient notes. The
real question is whether is a need to do things like
ligatures = { \[ s1 \] \[ s1 \] }
\new Voice \melody \ligatures
you'd have to ask jurgen reuter who wrote basically all the ancient
notation support.
It would work to do
ligatures = { s1\[ s1\]\[ \] }
If we say that's ugly, it's not like the situation would be any
different with () [] \(\)
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
[GLISS] Unifying \chordmode and \notemode
I actually remembered one thing that remains worth doing: integrating \chordmode into \notemode. \chordmode and \notemode are quite orthogonal, and there are actually only few differences: c means a major chord in chordmode, a note in notemode c: means a major chord in chordmode, a tremolo with the same durations as the last tremolo in notemode c:4 ... Basically, the conflicts are that _not_ using a colon means a single note vs. a major chord, and tremolo notation. Sacrifice tremolo notation, and you are almost there. Alternatively, find a different way of writing chords, like using / instead of :. While we are at it with \chordmode, the question is why the octave on chords is being ignored: c:m and c,:m are the same chord. Why would it make sense to have a unified mode? Being able to combine single notes in the same voice and partly in parallel or succession with full chords makes sense for the piano, the guitar, the accordion, and probably several other instruments. Having to switch modes or spell out standard chords all the time is an inconvenience. With all of these instruments, Um-pah kind of accompaniments alternating between a single bass note and a chord is rather frequent. Being able to write those out sequentially would be seriously simplifying things. This kind of change does not provide significant logical or coding challenges: indeed the most important aspect is working out the conflicts with existing syntax and choosing alternatives and sacrifices where collisions occur. Parser conflicts while working on this will be rather straightforward to interpret and will have to be resolved by discussion and decision-making rather than by coding tricks. This would actually be a syntax project meaningfully tackled by a community process, including making the decision of whether one wants to tackle it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uncommented code in LilyPond
Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 7:33 AM, David Kastrup d...@gnu.org wrote: Frightening rather. I don't spend enough time defending LilyPond against awful patches as it is. [...] It is easy to make it easier to meddle with LilyPond code. The low number of contributors is not due to our toolchains. It is because few people are comfortable poking around in the dark. And for good reason. While i agree with the problems you outline (not enough comments, maintenance timebombs etc), it's fascinating to observe that while i wouldn't say that you're a downright pessimist (and you certainly don't lack a sense of humour), so many of your emails are dark and menacing! ;-) An optimist is one willing to believe we are living in the best of all conceivable worlds. A pessimist is one who knows it. In the last few days, I have not done any serious coding. The most challenging achievement was probably my attempt of dooming to obliteration a whole bunch of code that Pál spent a lot of thought and work and polishing on without much feedback, without giving the impression that I am not valuing his work and efforts. And some of that might have been avoidable if I had really thought hard about this previously. Things had already moved in an unfortunate direction with unfortunate results before Pál even started on his project, and it actually took his try to sort things out better to make a detailed analysis of what we actually want, and agree on rules that are much more stupid than what he came up with. I don't want _anybody_ to experience the feeling of having wasted his time unnecessarily on something. We want to keep people motivated for working on LilyPond. And that means different things in the short run, and in the long run. The current discussions are also taking a lot of energy and don't make me particularly comfortable. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make decisions?
Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 3:34 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: Part of my beef with the GOP mediated discussion here is that just me and David have a grasp of how things work. Get more people knowledgeable and there can be discussion. Well, is there a better ways for us (other people) to get knowledgeable than to watch you two discuss and ask questions of our own during that discussion? No offence meant. I really think that's the way to do it: we all discuss, and - by the virtue of your knowledge - you lead the discussion. If you want to try messing with the parser, the integrate chordmode into notemode topic is a good starting point. Most of the reported parser conflicts in that process should bear a recognizable relation to an actual syntax issue. Of course, this suggestion is entirely unselfish, and nobody should suspect otherwise. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Janek Warchoł janek.lilyp...@gmail.com writes: c\p b --- no space before = postfix c -\p b--- explicitely postfix, space is no problem c \parenthesize b --- verb with a space before = prefix function c \mymusic b --- a noun with a space before = a variable That's nice, but i think it will not help when there are multiple events/functions around notes. With things like c-\parenthesize-\p no hard and fast syntax rule will resolve the ambiguity caused by your let's stick - before things applying to the previous element proposal. Both parenthesizing c as well as parenthesizing \p would be consistent with that dictum. Scheme is properly nested, LilyPond is basically agglomerating elements, and any agglomeration will lead to grouping ambiguities. Your proposal of using - selectively just provides two levels for that, but inside of each level, you get the same underlying ambiguity. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Sep 1, 2012 at 10:09 PM, David Kastrup d...@gnu.org wrote: Well, the music function work has removed a lot of pressure of the I want my favorite construct xxx in the grammar kind since there are quite a number of things people can put in themselves if they want to. Yes, the process of making music functions more versatile was quite undemocratic. But it was not as much that I was sole decision-maker, but rather that my skills and areas of interest were shaping the work I was doing, with a focus of making currently existing constructs reimplementable in Scheme. The direction that LilyPond's parser is taking is increasingly supporting _constructs_ as contrasted to _elements_. So there is much more inclination nowadays to ask oneself the question how can I express this with existing tools? rather than how can I fit this into the parser as well?. I'm not sure if i understand. Could you give some examples? \times has become a music function while maintaining its syntax. \time has become a music function, integrating some form of compound time command that had previously required spelling out the time fraction in Lisp form. \key has become a music function, including the possibility of writing \key\default. \mark has similarly become a music function, including writing \mark\default. If you want to have something with a similar syntax to all those preexisting commands, you can write it yourself. If you want to replace one of those commands with a personal modification, you can (since they no longer are reserved words). As a result, there is less pressure to discuss syntax additions for that kind of thing. \tweak got an optional grob argument looking just like it had been always there. This did not require parser discussions or changes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uncommented code in LilyPond
Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 1:00 PM, Graham Percival gra...@percival-music.ca wrote: I think that any time that a LilyPond developer complains that the code is too hard to understand, the patch should automatically move to Patch-needs_work. Automatically. If there's a long discussion and there's overwhelming opinion from other developers that the code is fine, then we could ignore the dissenting developer. But unless there's *overwhelming* opinion that the patch is fine, I think that a single complaint of readability should render the patch un-pushable. +1. Hmm, adopting this policy would make me the most feared reviewer in the community :-P Shrug. It is life insurance with the code as benefiter. Nobody wants to pay the premium, but if you don't, it won't survive for long after you lose life or just interest in it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] Unifying \chordmode and \notemode
Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Sep 3, 2012 at 11:46 AM, David Kastrup d...@gnu.org wrote: I actually remembered one thing that remains worth doing: integrating \chordmode into \notemode. This sounds like a nice project. I am still worried by the backward compat breakage, though. Is it worth it? That's something worth finding out. It will always be an option to keep a separate \chordmode for around that is falling into disuse, while figuring out a chord syntax for \notemode that is sufficiently similar to not require relearning and similarly not in conflict with existing use. So there definitely is potential to keep the breakage low. Of course, there will still be an incentive to eventually deprecate \chordmode if it turns out that it does nothing of additional value over \notemode. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] Unifying \chordmode and \notemode
David Kastrup d...@gnu.org writes: Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Sep 3, 2012 at 11:46 AM, David Kastrup d...@gnu.org wrote: I actually remembered one thing that remains worth doing: integrating \chordmode into \notemode. This sounds like a nice project. I am still worried by the backward compat breakage, though. Is it worth it? That's something worth finding out. Well, a useful ability to write single notes in sequence with chords is pretty essential for accordion music, but it is not like it would be untypical for piano ragtime or waltzes either. And not having to switch modes but rather being able to decide on a note-per-note basis how one wants to spell out things certainly is an advantage. There definitely is use for a hybrid mode. There is just the question how to fit it into LilyPond best. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Graham Percival gra...@percival-music.ca writes: On Mon, Sep 03, 2012 at 05:17:53PM +0200, David Kastrup wrote: With things like c-\parenthesize-\p no hard and fast syntax rule will resolve the ambiguity caused by your let's stick - before things applying to the previous element proposal. The hard and fast rule is - attaches to a note; = attaches to the prevous element. I don't think that we had a chance to get into that during the big meeting. the previous element is the same kind of thing. c-.=\parenthesize=\tweak #'color #red Now is the parenthesized . red, or is the paren red? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: To me, a Grand Input Syntax fixing of LilyPond, would amount to creating a syntax that strictly separates parsing and interpretation. This implies not only rethinking a lot of syntax, but also it means letting go of some of the flexibility and conciseness of the current format. This sound like a Right Thing to do, but i'm not knowledgeable enough to know what the results would actually be. Examples appreciated (hopefully some examples will show in other discussions). Well, one simple consequence would be that one can't define music functions in a document (their definition is interpretation, their use is parsing). The use of Scheme would be quite constrained, as reading it is parsing, evaluating it interpretation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] Unifying \chordmode and \notemode
Janek Warchoł janek.lilyp...@gmail.com writes: What about differentiating between notes and chords by case? a - note A - chord Likely a bit annoying for accordionists (who use the convention of lowercase for chords and uppercase for bass notes). But probably less so than most alternatives. Would you use Bes or BES? If the former, how would you write the equivalent of bes:dim ? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] Unifying \chordmode and \notemode
Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 4:46 PM, David Kastrup d...@gnu.org wrote: I actually remembered one thing that remains worth doing: integrating \chordmode into \notemode. Why would it make sense to have a unified mode? Being able to combine single notes in the same voice and partly in parallel or succession with full chords makes sense for the piano, the guitar, the accordion, and probably several other instruments. Having to switch modes or spell out standard chords all the time is an inconvenience. With all of these instruments, Um-pah kind of accompaniments alternating between a single bass note and a chord is rather frequent. Being able to write those out sequentially would be seriously simplifying things. That's and interesting idea! As for the ':' conflict, we could replace it with (for chords). [1] [...] [1] we're running out of ASCII characters... That's a shame ;P has no really convincing mnemonic value. The last time this was discussed (some years ago I think) it was suggested that ; looked almost like :. Not exactly an overwhelming reason, but likely beating . My personal gut feeling is that probably /, already used for separating a chord base, could possibly be used for introducing chords. It is not perfect: c1/7 can be c followed by 1/7, or it can be a seventh chord on c with the duration of a whole note. But c1 already can be pitch c followed by number 1 or a whole note c. The difference is that 1/7 is a lexical unit of its own. But this probably could be made to work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] verbifying music functions
Keith OHara k-ohara5...@oco.net writes: David Kastrup dak at gnu.org writes: Keith OHara k-ohara5a5a at oco.net writes: Graham Percival graham at percival-music.ca writes: Let's have a look at verbifying music functions. [and special-cases that look just like music functions to the user] balloonText = \addBalloonText I think that those commands basically retaining their last argument with extras could be \withBalloon \withFootnote but I am not particularly convinced that this really makes things easier for people. It might make things easier, if the direction of the preposition reminds us of the direction of application. bes a c b-\withBalloonTextAt #'(2 . 2) H (Apparently, and unsurprisingly, we all forgot which way balloonText works; it affects the item before.) Unless you use balloonGrob or so. And it only works on notes inside of chords and so forth and so on. The original \footnote* commands were modeled after the balloon commands, and I changed that since they were basically unusable. One should now change the balloon commands to mimic the footnote interface to make the redesign complete. But \footnoteOn ... (Too bad we didn't keep this as postfix Having c4\withFootnote was more natural. The case that looked funny was \breathe, because the breathing sign is attached to the following note, presumably for proper spacing.) c4 \breatheBefore g'8( e c e g4) There were a few other funny non-note cases as well. It also did not work for attaching footnotes to articulations itself. There actually was one iteration trying to work this approach. I agree that it had some appeal for footnoting notes. It was rather awfully inconsistent and quite ugly for non-notes, so I definitely believe we arrived at the best we can do. LilyPond's lenient (red-tape-free) grammar causes users (me, at least) trouble when they need to carefully study the manual examples what applies to what. (Try reading the docs on \balloonText !) I remember Mike just copied those for the footnote interface, and I flamed him like anything. Definitely something that warrants bringing into line with the footnote interface. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Werner LEMBERG w...@gnu.org writes: Chord repetition is a *central* part of piano music (and not only there). It really deserves a proper syntax, and I'm glad that we have it now. How come the pianists don't have it in the score then? Editing shortcuts have a nice place in editors. `q' is certainly more than an editing shortcut. q is one of those features that make LilyPond unfeasible as a storage format for music. I believe exactly the opposite. Uh, _storage_ format. Not human-oriented shorthand. The kind of thing for which MusicXML is feasible. I don't see how a memorize-with-delay-only-proper-chords-in-original-relative-octave-and-strip-some-configurable-information type command like q would facilitate better storage, which is what your exactly the opposite would imply. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
Thomas Morley thomasmorle...@googlemail.com writes: That said, now some thoughts ontopic: In most cases I'm quite fine with the current lily-syntax concerning the pre/post-commands. But there are cases I'd wish to be more consequent. Example: c-1\2\rightHandFinger #2 g Sometimes backslash, sometimes dash! Dash is required for single-character shorthands like -. -- -^ -_ -3 and similar. It is also required when a _music_ function returning an articulation follows (like \tweak ... -.). It is not required when an event function or a variable containing an articulation follows. You _can_ always add it. Well, c-1\2-\rightHandFinger #2 g'1 works, too. But c-1-\2-\rightHandFinger #2 g'1 not. Why wouldn't it? [trying it out] Pfft. You are right. I consider this a bug worth fixing. BTW, writing this post and looking for more examples I was surprised, that sometimes adding a dash to a post-command works already: c1-\startTextSpan f-\stopTextSpan It should always work, without exception. It is just that sometimes it is optional. Summarize: I'd vote for no extrem changes to the syntax, but to improve it slightly in a more consequent manner. Maybe it should be _possible_ to prepend a dash to every post-command. That's definitely the intent. Concerning music-functions, I think we should keep the current behaviour. Music-functions mostly affect a larger section of music, appending them to any single event would be curious, except this _is_ the wanted behaviour: c-\parenthesize-| I would like to have this become equivalent to c\parenthesize-| but it still requires some work to allow LilyPond to _first_ call a music function, _then_ decide whether the result is a post-event to be attached to the previous note. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] differentiating pre/post/neutral commands
David Kastrup d...@gnu.org writes: Thomas Morley thomasmorle...@googlemail.com writes: That said, now some thoughts ontopic: In most cases I'm quite fine with the current lily-syntax concerning the pre/post-commands. But there are cases I'd wish to be more consequent. Example: c-1\2\rightHandFinger #2 g Sometimes backslash, sometimes dash! Dash is required for single-character shorthands like -. -- -^ -_ -3 and similar. It is also required when a _music_ function returning an articulation follows (like \tweak ... -.). It is not required when an event function or a variable containing an articulation follows. You _can_ always add it. Well, c-1\2-\rightHandFinger #2 g'1 works, too. But c-1-\2-\rightHandFinger #2 g'1 not. Why wouldn't it? [trying it out] Pfft. You are right. I consider this a bug worth fixing. Issue 2808 URL:http://code.google.com/p/lilypond/issues/detail?id=2808 I expect this patch to go through uncontested. Should be even suitable for 2.16.1. Any more zero-day blunders? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
