Re: State of the pond
Le 20/04/2012 23:42, Graham Percival disait : On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote: Le 19/04/2012 21:30, Graham Percival disait : - nobody touches the release/unstable branch, other than translators, who may merge with that if they want to and don't break anything. The question of whether translators have a stable branch or not is a separate matter and has nothing to do with the release plans. It's just a question of how the translators want to organize themselves. Will you cherry-pick downloads from FTP, or should I push them directly on release/unstable? I'm not going to be cherry-picking downloads from FTP. If you think it's absolutely necessary to include those in the 2.16.0 release, and if you're not going to break anything, then push directly to release/unstable. We do not have a long history of flawless git actions from translations, so my preference would be not to touch anything. That said, I can't recall any problems from FTP updates, so it's probably ok. Sorry, I didn't express myself very well. I usually download updated po-files from FTP and push them to staging. It is important to have them with 2.16, since the About automatic language selection string seems to no longer be picked up from Documentation/po but from the binary's po. And some doc string, which I consider as important, have been modified. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Il 17/04/2012 23:40, Francisco Vila ha scritto: 2012/4/17 Federico Brunifedel...@gmail.com: Another solution could be keeping the current structure and changing only check-translation.py so that, when looking at the files in Documentation/snippets, it should check only the changes inside texidoc = and doctitle = strings. Yes, I intially thougth this. What made me to discard proposing it, is that it would break the 'elegancy' of the a file is outdated, mark it as such and show the differences principle. Not a part of a file if you know what I mean. Thinking twice... I realize that the regexp would only reduce the output of check-translation but the files would still be marked as outdated for most languages, because of the committishes. So, Francisco, your solution seems like the only way to go. Do you agree? (you know I always get confused about this subject ;-)) So I believe that the best solution would be: - moving the english texidoc= and doctitle= strings in a separate directory, e.g. Documentation/texidocs/ - changing makelsr.py so that also the english strings in Documentation/texidocs are included in the snippets This implies that snippets editors will have to search the title and description of snippets in a separate file. But it's not a big hassle, as they change very rarely. How do developers feel about it? Should we create an issue in the tracker? Thanks, Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Jean-Charles Malahieude lily...@orange.fr writes: Le 20/04/2012 23:42, Graham Percival disait : On Fri, Apr 20, 2012 at 07:38:06PM +0200, Jean-Charles Malahieude wrote: Le 19/04/2012 21:30, Graham Percival disait : - nobody touches the release/unstable branch, other than translators, who may merge with that if they want to and don't break anything. The question of whether translators have a stable branch or not is a separate matter and has nothing to do with the release plans. It's just a question of how the translators want to organize themselves. Will you cherry-pick downloads from FTP, or should I push them directly on release/unstable? I'm not going to be cherry-picking downloads from FTP. If you think it's absolutely necessary to include those in the 2.16.0 release, and if you're not going to break anything, then push directly to release/unstable. We do not have a long history of flawless git actions from translations, so my preference would be not to touch anything. That said, I can't recall any problems from FTP updates, so it's probably ok. Sorry, I didn't express myself very well. I usually download updated po-files from FTP and push them to staging. It is important to have them with 2.16, since the About automatic language selection string seems to no longer be picked up from Documentation/po but from the binary's po. And some doc string, which I consider as important, have been modified. I'd suggest that you do the same (namely push to staging), wait for migration into master, check that the result agrees with your expectations (I think the automated tests are not likely to cover this well) and then ask Graham for permission to cherry-pick the respective commit from master into release/unstable. Test again and push. And if there is anything like mysterious merge conflicts or whatever else, abort operations. Regarding do not have a long history of flawless git actions from translations, most problems have been with automatic or manual salvaging of mysterious conflicts. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Le 21/04/2012 10:57, Federico Bruni disait : Il 17/04/2012 23:40, Francisco Vila ha scritto: 2012/4/17 Federico Brunifedel...@gmail.com: Another solution could be keeping the current structure and changing only check-translation.py so that, when looking at the files in Documentation/snippets, it should check only the changes inside texidoc = and doctitle = strings. Yes, I intially thougth this. What made me to discard proposing it, is that it would break the 'elegancy' of the a file is outdated, mark it as such and show the differences principle. Not a part of a file if you know what I mean. Thinking twice... I realize that the regexp would only reduce the output of check-translation but the files would still be marked as outdated for most languages, because of the committishes. So, Francisco, your solution seems like the only way to go. Do you agree? (you know I always get confused about this subject ;-)) So I believe that the best solution would be: - moving the english texidoc= and doctitle= strings in a separate directory, e.g. Documentation/texidocs/ - changing makelsr.py so that also the english strings in Documentation/texidocs are included in the snippets This makes me believe it would be a good opportunity to have the English version follow the same rule as translations. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Hello, On 21 April 2012 10:13, Jean-Charles Malahieude lily...@orange.fr wrote: ... This makes me believe it would be a good opportunity to have the English version follow the same rule as translations. Err.. not sure what you mean by that technically but it's complicated enough with snippets as it is, to follow the translation method adds even more complexity (if the CG is anything to go by). Remember that unless you are doing this all the time (which the translators will be) it isn't that straightforward. We want to encourage contributors not push them away. From a very basic-no-progamming skill perspective, why can't we just have an extra texidoc entry in the snippet itself and add the translation manually, like we would for any updated snippet? Having another set of files to edit just to put in an explanation seems silly and now we have to link files to those as well? So in the NR we have an @snippet that links to a dir with the snippet that now has to link to a texidoc for that snippet in another dir. How is that better? In fact, why do we even need a texidoc string *inside* the snippet? I don't use one for @lilypond examples. Why not explicitly translate the snippet 'text' in the manual like we do for everything else. Wouldn't that be easier long term? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
On Sat, Apr 21, 2012 at 11:33:49AM +0100, James wrote: Err.. not sure what you mean by that technically but it's complicated enough with snippets as it is, to follow the translation method adds even more complexity (if the CG is anything to go by). +1 We want to encourage contributors not push them away. Arguably the complexity of the current system pushes translators away, so Jean-Charles' has a point there. However, I am extremely skeptical of any major work on this part of our build system and policies. Unless you know that you know more about the build system and LSR than I do[1], I really don't recommend getting into this. I see any work on this becoming a huge time sink which probably won't end up with a simpler system anyway. [1] John Mandereau is the chief candidate for this. From a very basic-no-progamming skill perspective, why can't we just have an extra texidoc entry in the snippet itself and add the translation manually, like we would for any updated snippet? Because then it would be overwritten whenever we do a LSR import. In fact, why do we even need a texidoc string *inside* the snippet? I don't use one for @lilypond examples. Because snippets come from LSR, and that needs a texidoc to display some text for the snippet. I really don't see any way to rescue the snippet system. It was a gamble that hasn't paid off; it was supposed to be a standalone system that would let normal unprivileged users contribute to the docs with almost no oversight by anybody with git access. With all the developer effort that's gone into build and maintaing it, we could have made it easier to do stuff in git and/or trained more doc editors. I view any major effort on the snippets as throwing good money after bad. Or, to put it more technically, it's reached the level of the sunk cost fallacy. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote: [1] why oh why does the main GNU editor not use the official extension language for the GNU operating system?? Same reason why its keyboard shortcuts are only so-so compatible with CUA and/or GNOME: its development was started more than 30 years ago, when nobody had ever heard of Guile. Note, however, one of this year's Google-Summer-of-Code projects is integrating guile into Emacs; the idea is to use guile as the interpreter for Emacs Lisp. At the same time, Scheme will be available for free. That sounds interesting. Personally I would rather see Emacs re-implemented using Common Lisp instead of Emacs Lisp. The languages are very similar but it is their very similarity that trips me up whenever I try to use Emacs Lisp. OTOH, I don't think I could live without Emacs! Cheers, Bernard. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Bernard Hurley bern...@marcade.biz writes: On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote: [1] why oh why does the main GNU editor not use the official extension language for the GNU operating system?? Same reason why its keyboard shortcuts are only so-so compatible with CUA and/or GNOME: its development was started more than 30 years ago, when nobody had ever heard of Guile. Note, however, one of this year's Google-Summer-of-Code projects is integrating guile into Emacs; the idea is to use guile as the interpreter for Emacs Lisp. At the same time, Scheme will be available for free. That sounds interesting. Personally I would rather see Emacs re-implemented using Common Lisp instead of Emacs Lisp. URL:http://common-lisp.net/project/climacs/ is one such thing, and the web site lists a number of other ports that failed to reach significant mindshare. Common Lisp is far too big to make sense as an extension language. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Regarding LSR translation work
Le 21/04/2012 12:33, James disait : Hello, On 21 April 2012 10:13, Jean-Charles Malahieudelily...@orange.fr wrote: ... This makes me believe it would be a good opportunity to have the English version follow the same rule as translations. Err.. not sure what you mean by that technically but it's complicated enough with snippets as it is, to follow the translation method adds even more complexity (if the CG is anything to go by). Remember that unless you are doing this all the time (which the translators will be) it isn't that straightforward. I mean that the tree should be the same for every language, or more precisely for every part of the documentation which might be translated. In my opinion, it is not well ordered when I see that text.itely does not lie at the same level when in English than in Czech or Chinese or French. We should keep, and why not move it in a Common or Shared subdir, all the material that is not supposed to be translated (CG and the non annotated pictures or headwords examples) as it is, and adopt the same tree for the normal documentations. Another way to go, but without my preference, would be do discard the directory per language structure and add a language suffix and have something like Documentation/learning/tweaks.LL.itely We want to encourage contributors not push them away. Agreed. It goes even worse for the translator's community! Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote: Bernard Hurley bern...@marcade.biz writes: On Sat, Apr 21, 2012 at 11:08:00AM +0200, Werner LEMBERG wrote: [1] why oh why does the main GNU editor not use the official extension language for the GNU operating system?? Same reason why its keyboard shortcuts are only so-so compatible with CUA and/or GNOME: its development was started more than 30 years ago, when nobody had ever heard of Guile. Note, however, one of this year's Google-Summer-of-Code projects is integrating guile into Emacs; the idea is to use guile as the interpreter for Emacs Lisp. At the same time, Scheme will be available for free. That sounds interesting. Personally I would rather see Emacs re-implemented using Common Lisp instead of Emacs Lisp. URL:http://common-lisp.net/project/climacs/ is one such thing, and the web site lists a number of other ports that failed to reach significant mindshare. Common Lisp is far too big to make sense as an extension language. True but I use the stump window manager so I have SBCL running anyway. Climacs doesn't seem to have progressed since 2008 and is nowhere near a drop-in replacement for Emacs. Anyway maybe this is getting a little far from Lilypond! Cheers, Bernard ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Bernard Hurley bern...@marcade.biz writes: On Sat, Apr 21, 2012 at 01:49:38PM +0200, David Kastrup wrote: Bernard Hurley bern...@marcade.biz writes: That sounds interesting. Personally I would rather see Emacs re-implemented using Common Lisp instead of Emacs Lisp. URL:http://common-lisp.net/project/climacs/ is one such thing, and the web site lists a number of other ports that failed to reach significant mindshare. Common Lisp is far too big to make sense as an extension language. True but I use the stump window manager so I have SBCL running anyway. It does not make more sense for the tail to wag the dog just because the dog would be there anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New template for 'lilypond' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to coordina...@translationproject.org.) A new POT file for textual domain 'lilypond' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/lilypond-2.15.37.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: http://download.linuxaudio.org/lilypond/sources/v2.15/lilypond-2.15.37.tar.gz We can arrange things so that translated PO files are automatically e-mailed to you when they arrive. Ask at the address below if you want this. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)
On 2012/04/15 20:06:55, Keith wrote: On 2012/04/15 16:45:54, Keith wrote: An improvement would be to round-to-larger Done, along with other cleanup following the similar function rest_collision_callback() The cleanup would seem to break layout totally. URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.general/71476 http://codereview.appspot.com/6035053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)
On 2012/04/21 16:10:09, dak wrote: The cleanup would seem to break layout totally. URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.general/71476 That's disappointing. The property 'previous_offset' sometimes has values comparable to the page height. On the early returns I'll return zero like the real (that is, not pure) rest_collision_callback() does. http://codereview.appspot.com/6035053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
scheme: working in guile but not in lilypond?
Hi, the following code gives me the expected output in guile: (define-public lst `()) (define (set-new-alist! ls-1 ls-2 proc) (for-each (lambda (x) (set! ls-1 (acons x proc ls-1))) ls-2) ls-1) (set-new-alist! lst '(1 2 3) X) == ((3 . X) (2 . X) (1 . X)) trying similiar in lily: \version 2.15.36 #(define-public lst `()) #(define (set-new-alist! ls-1 ls-2 proc) (for-each (lambda (x) (set! ls-1 (acons x proc ls-1))) ls-2) ls-1) #(set-new-alist! lst '(1 2 3) X) #(display lst) returns: () What am I missing? -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme: working in guile but not in lilypond?
Thomas Morley thomasmorle...@googlemail.com writes: Hi, the following code gives me the expected output in guile: (define-public lst `()) (define (set-new-alist! ls-1 ls-2 proc) (for-each (lambda (x) (set! ls-1 (acons x proc ls-1))) ls-2) ls-1) (set-new-alist! lst '(1 2 3) X) == ((3 . X) (2 . X) (1 . X)) trying similiar in lily: \version 2.15.36 #(define-public lst `()) #(define (set-new-alist! ls-1 ls-2 proc) (for-each (lambda (x) (set! ls-1 (acons x proc ls-1))) ls-2) ls-1) #(set-new-alist! lst '(1 2 3) X) #(display lst) returns: () What am I missing? There is no discrepancy. If you write (display lst) after the first case, it will also show just (). In either case, set-new-alist! returns the value shown above, and lst is left unchanged. Lisp is call-by-value. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
2012/4/20 Graham Percival gra...@percival-music.ca: We do not have a long history of flawless git actions from translations, so my preference would be not to touch anything. Good idea! The definitive recipe for eternal flawless development is not to touch anything, ever. Better safe than sorry. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: scheme: working in guile but not in lilypond?
\version 2.15.36 #(define-public lst `()) #(define (set-new-alist! ls-1 ls-2 proc) (for-each (lambda (x) (set! ls-1 (acons x proc ls-1))) ls-2) ls-1) #(set-new-alist! lst '(1 2 3) X) #(display lst) returns: () What am I missing? %% Well, if you change #(set-new-alist! lst '(1 2 3) X) by #(set! lst (set-new-alist! lst '(1 2 3) X)) It works. Seems that scheme works with a copy of the list lst. So you have to re-assign lst to the return of the function. If i have well understood how scheme works, the only way to avoid the set! is to use a function + a MACRO, Perhaps something like that : %%% #(define-public lst `())#(define-public lst `()) #(define (fill-list ls proc) (map (lambda (x) (cons x proc)) ls)) #(define-macro (set-new-alist! ls-1 ls-2 proc) `(set! ,ls-1 (fill-list ,ls-2 ,proc))) #(set-new-alist! lst '(1 2 3) X) #(display lst) % Gilles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the pond
Hello, On 22 April 2012 00:02, Francisco Vila paconet@gmail.com wrote: 2012/4/20 Graham Percival gra...@percival-music.ca: We do not have a long history of flawless git actions from translations, so my preference would be not to touch anything. Good idea! The definitive recipe for eternal flawless development is not to touch anything, ever. Better safe than sorry. Gosh! Talk about taking something out of context. No one said 'ever' - you said that, consider this a moment of 'reflection', if you want an analogy. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Footnote documentation error
Hello, On 22 April 2012 04:12, Mark Mathias d8val...@gmail.com wrote: So... as far as the Bug Squad is concerned, are we still waiting for something or does this need to get added to the tracker? Thanks, Mark As far as the bug squad are concerned - being one myself - we'd like a confirmation that this is a documentation error or an unexpected/inconsistent behaviour in the code. I haven't seen a case for either yet. james ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
