Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On Tue, Feb 25, 2020 at 11:09 PM wrote: > Another solution might be serialize only lilypond-book and let tex et > al. run concurrently. That should also be harmless, right? But this is exactly what this patch does. I don't understand your objection. Serializing mechanism in the makefile are

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On Wed, Feb 26, 2020 at 9:59 AM Han-Wen Nienhuys wrote: > In this patch, we create a "xxx.lock" file, which is a little ugly. > Let me see if we can lock the directory directly. you can't (it has to be a file.) see https://gavv.github.io/articles/file-locks/#common-features for more background.

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On Wed, Feb 26, 2020 at 9:19 AM wrote: > > A lock (a file lock, in this case) is the standard solution for > > serializing concurrent access to a shared resource (a standard > > problem). What is your objection against using a standard solution? > > Yes, locks are a standard solution, but file

Re: Getting download sizes right: proof of concept

>> I'd need someone to take this sketch and integrate it into the >> build system (I just don't really understand the build system). > > Do we really need this? Yes, I think this is *very* useful. It's always nice to know big file sizes (i.e., files larger than, say, 1MByte) in advance. Not

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/26 08:19:39, hahnjo wrote: > On 2020/02/26 07:59:36, hanwenn wrote: > > On Tue, Feb 25, 2020 at 11:09 PM wrote: > > > Another solution might be serialize only lilypond-book and let tex et > > > al. run concurrently. That should also be harmless, right?

Re: ly:page-turn-breaking core dumps

On Tue, Feb 25, 2020 at 11:56 PM Pierre-Luc Gauthier wrote: > Well, my system is more than a file. Anywho, I will provide a working > bug… it sadly wont be minimal though. > > You can send it by private mail. > > I'll prepare and send asap. I had a short look, but I'll need more time, which I

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/26 07:59:36, hanwenn wrote: > On Tue, Feb 25, 2020 at 11:09 PM wrote: > > Another solution might be serialize only lilypond-book and let tex et > > al. run concurrently. That should also be harmless, right? > > But this is exactly what this patch does.

Re: Getting download sizes right: proof of concept

On Wed, Feb 26, 2020 at 2:19 AM David Kastrup wrote: > > > I'd need someone to take this sketch and integrate it into the build > system (I just don't really understand the build system). Do we really need this? We could just delete the download size from text and be correct in a much simpler

Re: Getting download sizes right: proof of concept

Jean-Charles Malahieude writes: > Le 26/02/2020 à 02:18, David Kastrup a écrit : >> >> Anybody want to see what it takes to get this across the finishing line? >> > > Just a nitpick: the sizes are in Documentation/web/manuals.itexi. > I'll have a look this afternoon. Oh, I know. The

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/02/26 08:28:33, hahnjo wrote: > On 2020/02/26 08:19:39, hahnjo wrote: > > > On a philosophical level, it is a lilypond-book implementation detail > > > that it can't deal with concurrent invocation, so the remediation for > > > this problem should be in lilypond-book too. > > > > Let me

Re: Getting download sizes right: proof of concept

Le 26/02/2020 à 02:18, David Kastrup a écrit : Anybody want to see what it takes to get this across the finishing line? Just a nitpick: the sizes are in Documentation/web/manuals.itexi. I'll have a look this afternoon. Cheers, -- Jean-Charles

Re: Getting download sizes right: proof of concept

Werner LEMBERG writes: >>> I'd need someone to take this sketch and integrate it into the >>> build system (I just don't really understand the build system). >> >> Do we really need this? > > Yes, I think this is *very* useful. It's always nice to know big file > sizes (i.e., files larger

Re: Forge Software Evaluation by FSF

Am Mittwoch, den 26.02.2020, 14:56 +0100 schrieb Werner LEMBERG: > > I see they reviewed SourceHut, which seems to be actively trying to > > > comply with FSF's repository expectations. I'd come across SourceHut > > > earlier, and its minimalist design and a few other things reminded me > > > a

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

On 2020/02/22 23:22:43, dak wrote: > 在2020/02/22 22:08:33上，hanwenn寫道： > >在2020/02/22 22:01:10，lemzwerg寫道： > >>以前從未見過這樣的代碼，但是如果它解決了問題... :-) > > > >這是互聯網上的剪切和粘貼， > > https://blog.apokalyptik.com/2007/10/24/bash-tip-closing-file-descriptors/ > > > >我很驚訝在控制台stdin上將make傳遞給子進程，但是它 >

Re: Forge Software Evaluation by FSF

Am Dienstag, den 25.02.2020, 23:38 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Hi all, > > > > I was meaning to write on the next steps of switching to new tooling > > when I came across this: > > https://lwn.net/Articles/813254/rss > > > >

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

臭雞歪 https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

妓女 https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

On 2020/02/22 23:22:43, dak wrote: > 在2020/02/22 22:08:33上，hanwenn寫道： > >在2020/02/22 22:01:10，lemzwerg寫道： > >>以前從未見過這樣的代碼，但是如果它解決了問題... :-) > > > >這是互聯網上的剪切和粘貼， > > https://blog.apokalyptik.com/2007/10/24/bash-tip-closing-file-descriptors/ > > > >我很驚訝在控制台stdin上將make傳遞給子進程，但是它 > >確實發生了。 > >

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

幹你娘，全家死光 https://codereview.appspot.com/545620043/

Re: Forge Software Evaluation by FSF

> I see they reviewed SourceHut, which seems to be actively trying to > comply with FSF's repository expectations. I'd come across SourceHut > earlier, and its minimalist design and a few other things reminded me > a little of LilyPond's culture. SourceHut looks very nice! BTW, here's an FSF

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

On 哭爸 https://codereview.appspot.com/545620043/

Re: run-and-check: close stdin (issue 545620043 by hanw...@gmail.com)

On 2020/02/23 19:05:02, hanwenn wrote: > 在2020/02/23 06：28：27，lemzwerg寫道： > >>這裡正確的解決方法當然不是關閉stdin > >>而是使用以下命令運行pdflatex > >> > >-交互批處理模式 > >> > >>（在運行期間，它不會在輸出中顯示任何內容， > >>因此，如果出現以下情況，您需要查閱日誌文件 > >>問題）或 > >> > >-互動不間斷模式 > >> > >>從不停止輸入。 > > > >聽起來很明智。韓文你可以試試嗎 > > Done 去死

Re: Forge Software Evaluation by FSF

Han-Wen Nienhuys writes: > On Tue, Feb 25, 2020 at 11:23 PM Jonas Hahnfeld wrote: >> >> Hi all, >> >> I was meaning to write on the next steps of switching to new tooling >> when I came across this: >> https://lwn.net/Articles/813254/rss >>

Re: Use HTTPS for all search boxes (issue 563570043 by hanw...@gmail.com)

commit 99a9a5b304b72910c31593f3b434b4b47874ebbf Author: Han-Wen Nienhuys Date: Fri Feb 21 16:20:52 2020 +0100 Use HTTPS for all search boxes https://codereview.appspot.com/563570043/ https://codereview.appspot.com/563570043/

Re: Parse inline scheme using per-expression port (issue 557330043 by hanw...@gmail.com)

commit 483292eb80da0869d22cd773eb480c662a499e89 Author: Han-Wen Nienhuys Date: Tue Feb 18 09:40:00 2020 +0100 Parse inline scheme using per-expression port https://codereview.appspot.com/557330043/

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

> I'll really make myself unpopular here, […] No, that's what discussions are for. I probably shouldn't have uploaded a second patch set before the property name had finally been decided upon, but I was kind of urged by the countdown starting and didn't have the time for working on it earlier.

Re: Forge Software Evaluation by FSF

On Wed, Feb 26, 2020 at 11:06 PM David Kastrup wrote: > > There is also a bunch of verbiage about how tracking tags are evil. > > (lilypond.org has been running Google Analytics for 15 years or so). > > Because? We used it to improve our site layout and understand how people discovered

PATCHES - Countdown for February 26th

Hello, Here is the current patch countdown list. The next countdown will be on February 28th. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ *** Push: 5782 dump lilypond-book log files in $(outdir) -

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

https://codereview.appspot.com/557500043/diff/563610046/scm/define-grob-properties.scm File scm/define-grob-properties.scm (right): https://codereview.appspot.com/557500043/diff/563610046/scm/define-grob-properties.scm#newcode1374 scm/define-grob-properties.scm:1374: amount of space in case of

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/26 21:14:54, Be-3 wrote: > On 2020/02/26 21:04:59, Be-3 wrote: > > Changes applied following the reviewers' comments > > All of the recommendations applied: > > Rename stru Beam_stem_length -> Beam_stem_end (Han-Wen) > Rename property french-correction -> stem-end-shorten

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

On 2/26/2020 3:28 PM, Leandro Doctors wrote: Could you please point me in the right direction? Thanks for your interest! In the past, Urs Liska has been leading GSOC efforts. He's indicated that this list is his preferred way to begin GSOC discussions, so I think you're at the right place.

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/26 21:04:59, Be-3 wrote: > Changes applied following the reviewers' comments All of the recommendations applied: Rename stru Beam_stem_length -> Beam_stem_end (Han-Wen) Rename property french-correction -> stem-end-shorten (Han-Wen) Make property stem-end-shorten

Re: Forge Software Evaluation by FSF

Han-Wen Nienhuys writes: > On Wed, Feb 26, 2020 at 11:06 PM David Kastrup wrote: > >> > There is also a bunch of verbiage about how tracking tags are evil. >> > (lilypond.org has been running Google Analytics for 15 years or so). >> >> Because? > > We used it to improve our site layout and

Re: [GSOC 2020] Discussing GNU Lilypond project ideas?

Am Mittwoch, den 26.02.2020, 15:46 -0600 schrieb Karlin High: > On 2/26/2020 3:28 PM, Leandro Doctors wrote: > > Could you please point me in the right direction? > > Thanks for your interest! In the past, Urs Liska has been leading > GSOC > efforts. He's indicated that this list is his

Re: Forge Software Evaluation by FSF

On Tue, Feb 25, 2020 at 11:23 PM Jonas Hahnfeld wrote: > > Hi all, > > I was meaning to write on the next steps of switching to new tooling > when I came across this: > https://lwn.net/Articles/813254/rss > https://www.fsf.org/blogs/sysadmin/coming-soon-a-new-site-for-fully-free-collaboration >

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/26 21:50:05, lemzwerg wrote: > > How about > > * beamed-stem-french-adjustment > > * french-beaming-stem-adjustment > > …? > > I like the second one. I'd be fine with it. https://codereview.appspot.com/557500043/

Re: axis-group-interface: avoid some cast warnings (issue 583510045 by hanw...@gmail.com)

commit de02798e05dcfb08858f9041bdf2a8297a27f9be Author: Han-Wen Nienhuys Date: Thu Feb 13 14:44:01 2020 +0100 axis-group-interface: avoid some cast warnings https://sourceforge.net/p/testlilyissues/issues/5769 http://codereview.appspot.com/583510045

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

On 2020/02/26 21:56:46, dak wrote: > On 2020/02/26 21:50:05, lemzwerg wrote: > > > How about > > > * beamed-stem-french-adjustment > > > * french-beaming-stem-adjustment > > > …? > > > > I like the second one. > > I'd be fine with it. +1 https://codereview.appspot.com/557500043/

Re: Remove OMF support (issue 545630044 by hanw...@gmail.com)

https://codereview.appspot.com/545630044/diff/579320044/make/ly-rules.make File make/ly-rules.make (right): https://codereview.appspot.com/545630044/diff/579320044/make/ly-rules.make#newcode64 make/ly-rules.make:64: $(call ly_progress,Making,$@,< texi) On 2020/02/25 09:05:17, hahnjo wrote: >

Re: Issue 5788: New French Beamimg Approach (issue 557500043 by torsten.haemme...@web.de)

> How about > * beamed-stem-french-adjustment > * french-beaming-stem-adjustment > …? I like the second one. https://codereview.appspot.com/557500043/

[GSOC 2020] Discussing GNU Lilypond project ideas?

Dear all, My name is Leandro Doctors. I am seriously considering applying to GSoC 2020 with GNU Lilypond. I am interested in the Scheme-based ideas. (I have recently rediscovered LISP, and I am a Clojure fan.) However, I haven't found any indication on how to proceed the discussion in the Ideas

Re: How to report `FontForge` problems while creating LilyPond fonts

Sorry, my "turn" was a goof: The loop in the outline produced a tiny fissure… Now I've put a bit more effort in it, combining two subpaths at their intersection so that metapost's output will be a plain and simple outline, /exactly/ matching the original turn outline, but without any loops or

Our language downloads are chaotic.

For example, try downloading any French documentation from if your browser locale is not French. Possibly even if it is. I am currently setting up the size listings to correspond with the actual files linked there, but the

Re: How to report `FontForge` problems while creating LilyPond fonts

Werner LEMBERG wrote > The output produced by the `mf2pt1` script to convert METAFONT input files > to Type1 PostScript fonts often contains overlapping glyphs. This should > be > avoided in general.[1] For this reason, `mf2pt1` by default calls > `FontForge` in batch mode to remove overlaps.

Re: converting tabs to spaces in .mf files

>> What do you think about converting all tabs in the .mf files to >> spaces? > > I consider this a good idea. [...] OK, so I will do this within the next couple of days. Werner