Translated manuals on the website
I've been trying to trace why error messages occur in the build process, and that's led me to the translated docs. On the website, if I go to http://lilypond.org/website/development.it.html (for example) I can't find any links to translated documents. From the source, I know there are more docs that have been translated than I can see here: for example: @node Compilare un file @section Compilare un file @translationof Compiling a file I'm assuming I'm doing something stupid, but I'd like a pointer about how to find the translated versions on the web site. TIA. -- Phil Holmes Bug Squad ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translated manuals on the website
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Friday, April 29, 2011 12:52 PM Subject: Re: Translated manuals on the website On Fri, Apr 29, 2011 at 12:39:40PM +0100, Phil Holmes wrote: I've been trying to trace why error messages occur in the build process, and that's led me to the translated docs. On the website, if I go to http://lilypond.org/website/development.it.html (for example) You picked an awkward language; the Italian translation has only just begun. Look at es (Espanol) for a good (almost?) complete translation. Cheers, - Graham So the Italian text I can see in git is work in progress and won't be on the web site until it's completed? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translated manuals on the website
On Fri, Apr 29, 2011 at 01:31:18PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca On Fri, Apr 29, 2011 at 12:39:40PM +0100, Phil Holmes wrote: I've been trying to trace why error messages occur in the build process, and that's led me to the translated docs. On the website, if I go to http://lilypond.org/website/development.it.html (for example) You picked an awkward language; the Italian translation has only just begun. Look at es (Espanol) for a good (almost?) complete translation. So the Italian text I can see in git is work in progress and won't be on the web site until it's completed? Ooops, I just processed the lilypond.org part. The website, as built from git master, should not contain any broken links. If it does (and I don't doubt you), then that's a bug. In this case, I suspect a translation bug; somebody has the wrong @macros in one of the .itely or .itexi files. At the moment, I do not believe these broken links are caused from a build system bug. (but of course I will accept evidence to the contrary) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translated manuals on the website
2011/4/29 Phil Holmes m...@philholmes.net So the Italian text I can see in git is work in progress and won't be on the web site until it's completed? -- It's already available (website and a small part of Documentation v2.13). Here's the status: http://lilypond.org/translated.it.html If there is something wrong in the macros of italian files, I'll be glad to fix it (tomorrow). Let me know Cheers, Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets rid of unnecessary logic in beam.cc. (issue4449065)
On Apr 28, 2011, at 10:26 PM, Han-Wen Nienhuys wrote: On Thu, Apr 28, 2011 at 12:37 PM, mts...@gmail.com wrote: Reviewers: , Message: If I understand it correctly, Han-Wen's original collision code in beam.cc was treating intervals as if is_empty checked if they were uninitialized or invalid in some way, whereas in fact, is_empty gets rid of anything where left is greater than right. However, the LEFT and RIGHT values of intervals in collision_free contain y values for the beam position, and thus, the left one will invariably be higher than the right one if the beam has a negative slope. Thus, is_empty was (I think) ruling out any solution with a negative slope. I'm not sure if this is too drastic to address issue 1613 (there may need to be some error checking fit in), but I think that it more or less fixes the problem. Please read the code carefully to see what it does, rather than guessing: - Interval v = -(!collision_free[DOWN].is_empty()) ? -collision_free[DOWN] : -collision_free[UP]; - - beam_left_y = point_in_interval (v, 2.0); these are not beam slopes. From my reading of the code, collision_free[DOWN] and collision_free[UP] give tenable left and right y positions for a potential beam. is_empty returns true if the right entry of an interval is greater than the left entry. It thus rejects any collision_free[DOWN] or [UP] where the left entry is greater than the right entry (or, in other words, it rejects anything where the left side is higher than the right side (negative slope)). I'm sorry that I'm not getting what it is, but this is the best I could do by mulling over it and using lots of printf's. If it's not doing this, could you please describe what it is doing? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translated manuals on the website
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org; Francisco Vila paconet@gmail.com Sent: Friday, April 29, 2011 1:44 PM Subject: Re: Translated manuals on the website On Fri, Apr 29, 2011 at 01:31:18PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca On Fri, Apr 29, 2011 at 12:39:40PM +0100, Phil Holmes wrote: I've been trying to trace why error messages occur in the build process, and that's led me to the translated docs. On the website, if I go to http://lilypond.org/website/development.it.html (for example) You picked an awkward language; the Italian translation has only just begun. Look at es (Espanol) for a good (almost?) complete translation. So the Italian text I can see in git is work in progress and won't be on the web site until it's completed? Ooops, I just processed the lilypond.org part. The website, as built from git master, should not contain any broken links. If it does (and I don't doubt you), then that's a bug. In this case, I suspect a translation bug; somebody has the wrong @macros in one of the .itely or .itexi files. At the moment, I do not believe these broken links are caused from a build system bug. (but of course I will accept evidence to the contrary) Cheers, - Graham I don't see broken links on the web site. It's just that updating.itely in git has lot's of Italian there, and I can't locate that on the web site. updating is part of usage, and from the Italian web site, usage points to the English docs. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets rid of unnecessary logic in beam.cc. (issue4449065)
On Fri, Apr 29, 2011 at 9:59 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Apr 28, 2011, at 10:26 PM, Han-Wen Nienhuys wrote: On Thu, Apr 28, 2011 at 12:37 PM, mts...@gmail.com wrote: Reviewers: , Message: If I understand it correctly, Han-Wen's original collision code in beam.cc was treating intervals as if is_empty checked if they were uninitialized or invalid in some way, whereas in fact, is_empty gets rid of anything where left is greater than right. However, the LEFT and RIGHT values of intervals in collision_free contain y values for the beam position, and thus, the left one will invariably be higher than the right one if the beam has a negative slope. Thus, is_empty was (I think) ruling out any solution with a negative slope. I'm not sure if this is too drastic to address issue 1613 (there may need to be some error checking fit in), but I think that it more or less fixes the problem. Please read the code carefully to see what it does, rather than guessing: - Interval v = - (!collision_free[DOWN].is_empty()) ? - collision_free[DOWN] : - collision_free[UP]; - - beam_left_y = point_in_interval (v, 2.0); these are not beam slopes. From my reading of the code, collision_free[DOWN] and collision_free[UP] give tenable left and right y positions for a potential beam. is_empty returns true if the right entry of an interval is greater than the left entry. It thus rejects any collision_free[DOWN] or [UP] where the left entry is greater than the right entry (or, in other words, it rejects anything where the left side is higher than the right side (negative slope)). the UP and DOWN are vertical. This decides whether to go above or below collisions. the result goes into beam_left_y, so it only refers to left side of the beam. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translated manuals on the website
On Fri, Apr 29, 2011 at 02:02:14PM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca On Fri, Apr 29, 2011 at 01:31:18PM +0100, Phil Holmes wrote: The website, as built from git master, should not contain any broken links. If it does (and I don't doubt you), then that's a bug. In this case, I suspect a translation bug; somebody has the wrong @macros in one of the .itely or .itexi files. I don't see broken links on the web site. It's just that updating.itely in git has lot's of Italian there, and I can't locate that on the web site. updating is part of usage, and from the Italian web site, usage points to the English docs. Ok then, no problem. When the translator(s) think that updating is ready, they'll modify their language's version of web/community.itexi @node Development, to include a link to their version. Until they think it's ready for public viewing, they should just keep the link to the English version. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 04/15/2011 07:05 PM, Carl Sorensen wrote: Just to be sure I understand correctly, the only things I will cherry-pick into stable/2.14 will be bugfixes for critical bugs. Just as a remark, I wonder if you may find it easier to adopt an alternative workflow: -- bugfix gets applied first in 2.14 branch -- bugfix gets merged into master dev branch since that probably reduces the amount of cherry-picking that's needed -- I expect that probably almost every patch applied to 2.14 is also applicable to dev, but not vice versa. Best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching
On 4/29/11 9:55 AM, Joseph Wakeling joseph.wakel...@webdrake.net wrote: On 04/15/2011 07:05 PM, Carl Sorensen wrote: Just to be sure I understand correctly, the only things I will cherry-pick into stable/2.14 will be bugfixes for critical bugs. Just as a remark, I wonder if you may find it easier to adopt an alternative workflow: -- bugfix gets applied first in 2.14 branch -- bugfix gets merged into master dev branch since that probably reduces the amount of cherry-picking that's needed -- I expect that probably almost every patch applied to 2.14 is also applicable to dev, but not vice versa. This might work, but fails to meet the major criterion of the proposed branching scheme. The proposal is to make 2.14 stable. Actually, I think your final comment is backwards. Every patch is applicable to dev, but only some are applicable to 2.14. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: branching isn't working
Graham Percival graham at percival-music.ca writes: On Thu, Apr 28, 2011 at 02:45:07PM +0100, Graham Percival wrote: We can't just change VERSION in git master, because that's used to generate the website, oh wait, I just remembered that we have a separate MINOR_VERSION from VERSION_DEVEL. I encourage you to implement your branching plan ... somehow. I don't know exactly how, but it seems there is plenty of possibilities if you are willing to shepherd the build. Given that the branch labeled 'stable/2.14' will generate the next few builds, with version numbers 2.13.61 etc., I had imagined it might generate the website as well for a while. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
