Re: Use a pointer for the output parameter of Lily_lexer::scan_word (issue 577440044 by hanw...@gmail.com)

On Feb 1, 2020, at 09:59, David Kastrup wrote: > > even with a reference parameter. Of course this does not "really" give > an indication about this being in-out, but neither does That's an important point. What indicates that a parameter is _not_ an out-parameter is "const". You might

Regtest profiling differences

I've noticed a subjective increase in profiling differences in regtests since updating to the latest master this morning (bc8a3fa7e4f12bf5ac1eb0293bfab658d52c4ae8), even from one run to another on unchanged code. There are also log differences that might be correlated, with some test cases

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

On Feb 1, 2020, at 06:39, David Kastrup wrote: > >> You provided a lot of good information in your post, but the >> conclusion was not entirely clear. >> Are you suggesting requiring SSE2 at this time? > > Yes. It appears to get used anyway for 64bit executables, and it seems > safe enough to

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

On Feb 1, 2020, at 05:05, David Kastrup wrote: > > Frankly, I think that it would be better if our Windows executables just > moved to 64bit but that seems like the more complicated option yet. And > 32bit systems kept around a whole lot longer even after processors > became 64bit-capable

Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by hanw...@gmail.com)

On Jan 31, 2020, at 13:33, hanw...@gmail.com wrote: > > On 2020/01/31 18:22:47, Dan Eble wrote: >> On 2020/01/31 17:52:45, hanwenn wrote: >>> you can do a local alias >>> >>> vector<> = *vec; >>> >>> to aid readability. >&

Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)

On Jan 31, 2020, at 08:31, David Kastrup wrote: > -fexcess-precision=style > This option allows further control over excess precision on > machines where floating-point operations occur in a format > with more precision or range than the IEEE standard and >

Re: PropertySet with unbound value

On Jan 30, 2020, at 19:28, David Kastrup wrote: > > It's conceivable that the code was dead afterwards. I am not sure. Seems likely to me. https://codereview.appspot.com/557260047/ — Dan

PropertySet with unbound value

Does anyone have an idea of input I could provide to reach the block with the TODO below? I've tried #(make-music 'PropertySet 'symbol 'fingeringOrientations) (note that no value is defined), but it wasn't enough. TIA. void Context::set_property_from_event (SCM sev) {

Re: stable/2.20 branch does not complete "make doc"

f99406cd415c4b7d1f7349cd3e17ed73e69 Author: Dan Eble Date: Wed Oct 23 09:26:24 2019 -0400 Issue 5583: www_post.py: don't mirror regtest baseline -- Dan

Re: stable/2.20 branch does not complete "make doc"

On Jan 30, 2020, at 13:39, David Kastrup wrote: > >> I just had a successful mage -j5 doc as of commit >> 8a05312fd8d2a56ec724a793b313949db0cfe729 > > Current stable/2.20 which failed on my system. I also am not able to reproduce the problem in a clean workspace; but I have verified that I

Re: stable/2.20 branch does not complete "make doc"

On Jan 30, 2020, at 11:39, David Kastrup wrote: > That's not a new development, so there is no point in me to refrain from > cherry-picking further material: the last version of the branch I > checked was from early December and it failed in the same manner. > Compilation of CPU_COUNT=9 make -j9

Re: Clean up embedded scheme parsing/evaluation. (issue 577410045 by hanw...@gmail.com)

On Jan 30, 2020, at 04:54, hanw...@gmail.com wrote: > > This may predate you, but the decision to not store references was > intentional, > exactly because storing NULL in them is very useful. If you have a > reference, > it has to be initialized in the constructor, and this introduces a lot >

Re: 2.91.84 - windows-only bugs

> On Jan 29, 2020, at 10:17, Masamichi Hosoda wrote: > >> I ask because, in the german forum Arnold found a method to cure some >> windows-only bugs., about mis-predicted force and probably several >> assertion-failures: >> https://lilypondforum.de/index.php/topic,609.msg3463.html#msg3463 >

Re: automated formatting

On Jan 28, 2020, at 12:11, Carl Sorensen wrote: >Can you provide me with a presubmit hook that applies fixcc? Can you >guarantee that, if fixcc has run on the code, there will be no further >remarks on code formatting during review? > > I think that it's a really good idea to have

Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by nine.fierce.ball...@gmail.com)

On Jan 27, 2020, at 10:13, David Kastrup wrote: > > None relevant to GCC and Clang as far as I can see. Can you clarify for > which platforms you expect a practical concern? No. That would require a level of effort that is a reason I never mentioned these things before. — Dan

Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by nine.fierce.ball...@gmail.com)

On Jan 27, 2020, at 09:33, David Kastrup wrote: > >> I would like to replace the following with standard types (uint8_t >> etc.). The standard types are portable, but these are not. ... >> * flower-proto.hh:typedef unsigned U32; >> * flower-proto.hh:typedef int I32; ... > I don't really mind

Re: automated formatting

On Jan 27, 2020, at 07:43, David Kastrup wrote: > > Frankly, I just forgot about either. I think it would be a good idea to > take up this practice again. Regarding Clang: unless Astyle falls apart > using C++11 constructs that are going to occur more frequently in > future, I think there is

Re: Issue 5698: int->vsize in various alignment and page-layout methods (issue 563420043 by nine.fierce.ball...@gmail.com)

On Jan 27, 2020, at 03:26, hanw...@gmail.com wrote: > > LGTM > > Not for this change, but could we do a global > > vsize -> size_t > > search & replace. Do we have a reason to keep our own typedef for this? I fully support this. I wasn't going to bring it up yet because I worried that it

Re: Issue 4550: Avoid "using namespace std; " in included files (Take 2) (issue 579240043 by nine.fierce.ball...@gmail.com)

On Jan 25, 2020, at 07:26, David Kastrup wrote: > > - Interval hex = head->extent (common_[X_AXIS], X_AXIS); > + Interval head_ext = head->extent (common_[X_AXIS], X_AXIS); ... > > That last part applies part of a patch from an unrelated issue of > Han-Wen. Please don't do stuff like

Re: gub fail/local-build-script/new bug?

On Jan 24, 2020, at 16:19, David Kastrup wrote: > > It may be enough to call GCC with --std=g++11 (?) option without > updating GCC itself, but I don't really have an idea. GUB is using GCC 4.9.4 [1]. I've compiled the following program with Compiler Explorer [2] using that version of g++:

Re: gub fail/local-build-script/new bug?

d.git-master/flower/include/interval.tcc:142:14: >> error: 'std::to_string' has not been declared ... >> Probably: >> >> commit 9cf6b20aefd79be13c7678d4cc834434b7ca000d >> Author: Dan Eble >> Date: Sat Jan 11 08:55:36 2020 -0500 >> >>Issue 565

Re: Simplify and speed up uniquify (issue 583390043 by hanw...@gmail.com)

On Jan 24, 2020, at 11:11, d...@gnu.org wrote: >> Don't assume the hash function is perfect: create the table with more > buckets, >> say 2*size. > > I'd not do that. It's second-guessing the implementation. The size > should be good as a hint. In particular if there are actual > duplicates...

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

On Jan 24, 2020, at 03:49, Han-Wen Nienhuys wrote: > The alternative is that we don't cast it, but pass on the 64 bit size_t, but > every time we do that, we'll create new call sites where we have to fix up > conversions, so that will create more work for ourselves, I've been trickling in

Re: lily: fix some type conversion warnings (issue 557190043 by hanw...@gmail.com)

On Jan 24, 2020, at 03:49, Han-Wen Nienhuys wrote: > > (I think Dan is nine.fierce.ballads?) sort(Dan.full_name) == sort('ninE Fierce ballaDs') — Dan

Re: packaging lilypond as a docker container?

On Jan 21, 2020, at 11:01, Michael Käppler wrote: > > Would be happy to try the Dockerfile, since I've never used Docker > before and find > the concept interesting. > Could you push your changes to your LilyDev fork and/or file a pull > request against > Federico's repo? Federico has merged a

Issue #4550 Avoid "using" directives in included files

Begin forwarded message: > > From: "pkx166h" > Subject: [testlilyissues:issues] #4550 Avoid "using" directives in included > files > Date: January 22, 2020 at 10:13:39 EST > To: "[testlilyissues:issues] " > <4...@issues.testlilyissues.p.re.sourceforge.net> > Reply-To: "[testlilyissues:issues]

Re: Context paths (and the Edition Engraver)

On Jan 21, 2020, at 14:37, David Kastrup wrote: > > StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2 OK. It would be an understandable growth on the current face of LilyPond. :) Questions follow, but I'm not asking you to spend time investigating. Do you think we could achieve

Re: Context paths (and the Edition Engraver)

On Jan 21, 2020, at 14:02, Carl Sorensen wrote: > It seems to me that > > \context StaffGroup ID1.ID2.ID3.ID4 ... > ID4 must be a bottom context Please guide me step by step to this conclusion. All this example speaks to me is that ID4 is a great-grandchild of ID1. Thanks and regards, —

Re: Context paths (and the Edition Engraver)

On Jan 21, 2020, at 14:20, David Kastrup wrote: > >> Notation borrowed directly from them will not integrate well >> into LilyPond, but it might be fruitful to ask how we could modify >> expressions like these to fit in. ... > The syntax appears not to be a good match to LilyPond even though the

Re: Context paths (and the Edition Engraver)

On Jan 21, 2020, at 14:02, Carl Sorensen wrote: > \new ChoirStaff = choir << >\new Staff = choir.upper << >\new Voice = choir.upper.soprano >\new Voice = choir.upper.alto >>> > \new Staff = choir.lower << >\new Voice = choir.lower.tenor >\new Voice =

Re: Context paths (and the Edition Engraver)

On Jan 21, 2020, at 11:31, Jan-Peter Voigt wrote: > > \context Voice = choir.soprano > > it would be inconsistent with \new = "…" The implied example \new Voice = choir.soprano { … } could be given a consistent interpretation. For example, it could be interpreted as creating \new Voice

Re: Context paths (and the Edition Engraver)

On Jan 21, 2020, at 11:31, Jan-Peter Voigt wrote: > I'd like that, though it would be a quite invasive change. > And if we stay with the string for the context id and then use > lists/paths in the \context statement like > \new Staff = "choir" << \new Voice = "soprano" … > > and then use >

Re: packaging lilypond as a docker container?

On Jan 20, 2020, at 18:21, Karlin High wrote: > > There already is a LilyDev Docker image. > > > > I tried it once, but was unable to get it working. It was my first and only > experience with Docker, so that's probably my fault. I was

Re: github mirror of lilypond?

On Jan 20, 2020, at 11:51, pkx1...@posteo.net wrote: > > On 20/01/2020 16:16, Werner LEMBERG wrote: >>> Trivial things from a developer with push access can be just pushed. >>> Complex or otherwise contential things warrant a chance for >>> developers to take a look at it. "Half a chance" seems

Re: github mirror of lilypond?

On Jan 20, 2020, at 11:40, Carl Sorensen wrote: > I agree. And while comments during countdown are annoying and frustrating, > it's even more annoying and frustrating to have a commit reverted. So I > prefer countdown to reversion. +1 — Dan

Context paths (and the Edition Engraver)

One of the things in Kieren's intro to the Edition Engraver (EE) that resonated with me was the context paths. His example was something like `singwithbach.along.Voice.B`, which was supposed to refer to something like this: \context Staff = "along" { \context Voice = "B" { ...

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

On Jan 15, 2020, at 09:00, jonas.hahnf...@gmail.com wrote: > What's causing problems is that the configure (and only that) > usually lives in the source directory. In fact, I think you can make the > source directory read-only right after running autoconf, everything else > should only touch the

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

On Jan 15, 2020, at 03:08, jonas.hahnf...@gmail.com wrote: > > Maybe I misunderstood your process; aren't you firing up a fresh > container for every build? No, I leave the container running, open an interactive shell into it, and use it for a relatively long time. It is quite like how a VM

Savannah push access question

I recently started using a git GUI, GitUp, which sometimes infers that I might want to delete origin/staging, and offers to do it for me. Needless to say, I don't want that; and I've suggested in the GitUp issue tracker that even prompting me is a defect, in the light of this project's

Re: macOS 64-bit

On Jan 11, 2020, at 08:40, Marnen Laibow-Koser wrote: > Dammit, I did already fix this error! I wonder if I left the modified > gs.reloc file out of the bundle by mistake, or if something else is going on. > > > Would you post the contents of >

Re: macOS 64-bit

On Jan 11, 2020, at 07:48, Marnen Laibow-Koser wrote: > > Could you try it without renaming and see if you get the same results? > (Renaming shouldn’t actually matter, but I want to make sure I didn’t do > something stupid.) same result > There was the usual security problem with running

Re: macOS 64-bit

On Jan 11, 2020, at 01:36, Marnen Laibow-Koser wrote: > I'd really appreciate fellow Mac users testing the build and reporting any > issues you find. (Karlin? Carl?) You can download it at > https://drive.google.com/open?id=18b1nX5nJsBrzDBGqga9T753oCL8ilwqs ; it > should work on any recent

Re: GUB build error

On Jan 10, 2020, at 16:21, Dan Eble wrote: > > It seems that this implementation of the standard library declares ::isinf > when is included. The three solutions I can think of are (a) > finish issue 4550, (b) require a version of the library that does not do > this, or

Re: GUB build error

On Jan 10, 2020, at 15:52, Michael Käppler wrote: > > Hi Dan, > GUB still fails to build lilypond in offset.cc. See attached log. > Anyone out here using LilyDev1, who can build current master through GUB? > Now testing, if I can build release/unstable. > > What I would like to understand is

Re: GUB build error

On Jan 9, 2020, at 10:09, Dan Eble wrote: > > On Jan 9, 2020, at 07:32, Michael Käppler wrote: >> >> /home/dev/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/offset.cc:132:23: >> error: call of overloaded 'isinf(Real&)' is ambigu

Re: MacOS 64-bit build

On Jan 9, 2020, at 07:00, Erlend Aasland wrote: > > Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison > lists): a stream pointer has been changed in the declaration to a reference > without doing it in the code. Reported some years ago on the flex list. I've been

Re: GUB build error

On Jan 9, 2020, at 07:32, Michael Käppler wrote: > > /home/dev/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-master/flower/offset.cc:132:23: > error: call of overloaded 'isinf(Real&)' is ambiguous >if (isinf (d[X_AXIS])) Maybe it's time to take another shot at issue 4550,

Re: The Future

On Jan 8, 2020, at 12:53, Zone Dremik wrote: > > I'm bound to ask; is this the end of for support of Mac OS? I suggest checking the lilypond-devel archive, where people have been discussing macOS this very day. https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg00052.html — Dan

Re: Weird intermediate context creation

On Jan 7, 2020, at 09:26, Dan Eble wrote: > > On Jan 6, 2020, at 17:01, David Kastrup wrote: >> >>>> If I write >>>> >>>> << \new Staff { c' } \new Voice { d' } >> >>>> >>>> should the d' insinuate itself

Re: Weird intermediate context creation

On Jan 6, 2020, at 17:01, David Kastrup wrote: > >>> If I write >>> >>> << \new Staff { c' } \new Voice { d' } >> >>> >>> should the d' insinuate itself into the same staff as the c' ? >> >> You didn't specify a staff for the d', so I don't see grounds for >> dissatisfaction if LilyPond were

Re: Weird intermediate context creation

On Jan 6, 2020, at 10:57, David Kastrup wrote: >> the current result is strange > > Can you explain why you feel that? I find it strange that this music produces these diverse results: music = << c' e' >> \new Score { % Case A: two notes in one voice \new Voice \music } \new Score { % Case

Weird intermediate context creation

I find it strange that this code in input/regression/bend-bound.ly ends up on two staves rather than one: music = \repeat unfold 16 { c''4\bendAfter #-4 } sixteens = \repeat unfold 64 { c'16 } \new Score { << \music \sixteens >> } I have a pretty good idea of why it is happening, and I am

Re: A suggestion: add \rf to built-in dynamics

On Jan 4, 2020, at 06:09, Peter Toye wrote: > > Thanks for that. As everyone seems to be on all the mailing lists. I sort of > assumed that cross-links wouldn't be necessary. I am subscribed to lilypond-devel only. — Dan

Re: What is holding up 2.20 release?

On Dec 17, 2019, at 13:58, Jonas Hahnfeld wrote: > I would also propose to pick the following, more recent commits: > […] > 86de0f8f38 Use a stable sort when ordering MIDI items > 152a281031 Issue 5217: Fix sorting order without outside-staff-priority Pretty please, pick these. I support not

Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)

On Dec 15, 2019, at 06:31, lilyp...@de-wolff.org wrote: > It is not the commit title, but I do think that this is not a part of issue > 5639: compile with --std=c11 > The reason that I think it is important to keep this separated is that the > impact is very different. > When a commit with only

Re: make test-baseline fails

On Dec 7, 2019, at 04:36, Thomas Morley wrote: > > Btw, to get access to the "flip"-functionality I need to allow it in > NoScript of my firefox. Intended? Yes. It requires JavaScript, as do the filter links at the top. — Dan

Re: make test-baseline fails

On Dec 7, 2019, at 05:43, James wrote: > > So apart from 'required' things breaking as newer versions come out (e.g > Ghostscript), should I be testing patches with required AND non-required > components installed? Or should I be testing them with ONLY required > components but then we should

Re: make test-baseline fails

>>> $ tidy --version >>> HTML Tidy for Linux version 5.2.0 >> >> I'll try to get it and fix the issue. https://codereview.appspot.com/551250043/ — Dan

Re: make test-baseline fails

On Dec 6, 2019, at 13:54, Thomas Morley wrote: > >> This is tidy complaining about index.html. What version of tidy do you have >> (tidy --version)? My build environment has 5.6.0 and it isn't complaining. > > $ tidy --version > HTML Tidy for Linux version 5.2.0 I'll try to get it and fix

Re: make test-baseline fails

On Dec 6, 2019, at 12:32, Thomas Morley wrote: > > Validating > /home/hermann/lilypond-git-guile-2.2/build/out/test-results/index.html > line 73 column 76 - Warning: attribute "alt/" lacks value > line 79 column 169 - Warning: attribute "alt/" lacks value > line 73 column 76 - Warning: lacks

Re: compiler flag issues

On Nov 28, 2019, at 03:13, Werner LEMBERG wrote: > > This is very, very non-standard and completely undocumented. Not completely undocumented. The CG has said to run configure with --disable-optimising for as long as I can remember. > Any idea how this could be improved? A good start would

Re: create code tests

On Nov 29, 2019, at 16:20, wrote: > > I am familiar with the use of makefile. So if you can give me directions with > some placeholder commands, or comment at the right place in the makefile (s) Well, start at the "test" target in the top-level GNUmakefile.in. It runs make in a number of

Re: create code tests

On Nov 28, 2019, at 19:22, Dan Eble wrote: > > Well, step one is to avoid intertwining the existing xml->ly test > infrastructure with the new ly->xml test infrastructure. I would put ly->xml > test input in a different directory. I would probably also plan to renam

Re: create code tests

> On Nov 28, 2019, at 18:57, James wrote: > > hello > > On 28/11/2019 21:00, Dan Eble wrote: >> On Nov 28, 2019, at 15:07, lilyp...@de-wolff.org wrote: >> >>> Is het possible to do this kind of tests in the current lilypond regression >>> t

Re: create code tests

On Nov 28, 2019, at 15:07, lilyp...@de-wolff.org wrote: > Is het possible to do this kind of tests in the current lilypond regression > test environment? Jaap, I don't have a comprehensive knowledge of LilyPond's tests, but I have worked on some of the infrastructure recently, so maybe I can

Re: Midi block gives errors with bar number checks

On Nov 27, 2019, at 14:19, Dan Eble wrote: > > On Nov 27, 2019, at 12:06, Carl Sorensen wrote: >> >> From the user point of view, the ideal solution would be that if a score >> that includes bar number checks was handled by a midi block , the bar >>

Re: Midi block gives errors with bar number checks

On Nov 27, 2019, at 12:06, Carl Sorensen wrote: > > From the user point of view, the ideal solution would be that if a score that > includes bar number checks was handled by a midi block , the bar number > checks would be ignored. That's probably easily achievable. I'm looking at the

Re: Midi block gives errors with bar number checks

On Nov 27, 2019, at 11:35, Carl Sorensen wrote: > > It’s not bar checks causing the problem, it's bar number checks. Oh, thanks for the correction. It doesn't look difficult to add a context property to deactivate bar number checks. Would that be the ideal solution? — Dan

Re: Midi block gives errors with bar number checks

> On Wed, 27 Nov 2019 10:51:15 +0100 (CET), Martin Tarenskeen > wrote: > >> I use MIDI output mainly for proofreading, but at occasions where I need >> better MIDI output I always create separate scores for layout{} and >> midi{}. In the midi-only version I copy/paste all music in the correct

Yaffut

What level of respect should I maintain for the integrity of flower/include/yaffut.h? I think it would be nice to limit the default output of the unit test program to errors + summary, and I could achieve that either by modifying Yaffut itself or by filtering the output through a script. —

Re: Cannot build changes.pdf anymore

On Nov 23, 2019, at 08:06, Malte Meyn wrote: > > Yes, I wanted to save time and build only that single document. For that I > followed the CG: > http://lilypond.org/doc/v2.19/Documentation/contributor/generating-documentation#building-a-single-document > I ran these commands in my build

Re: problem with git pull -r

On Nov 21, 2019, at 10:30, Werner LEMBERG wrote: > Clone the repository anew, and everything should be fine again. > > Don't forget to `transfer' your old local branches before deleting the > old repository clone! I only had two local ones, so it was rather > easy. But I guess some of you have

git-cl patch: remove some redundant text from tracker fields

Please review. This handles a couple of details I'd rather not have to remember to do when submitting the patch or fix after the fact. I've exercised these changes for the last few LilyPond patches I've uploaded. https://github.com/gperciva/git-cl/pull/6 Thanks, — Dan

Re: Can no longer build.

On Nov 8, 2019, at 09:11, David Kastrup wrote: > > So how come my lilypond-invoke-editor script starts with > > "echo no not found -s" > > as its interpreter? Note that some underlying problem might not be new: 1. What does "grep -w GUILE config.make" tell you? (Will be the same, I guess.)

Re: git-cl upload and existing sf issues

On Nov 2, 2019, at 12:35, Dan Eble wrote: > >> when uploading a first patch set, git-cl asks for a sourceforge issue >> number. If a new issue is created, everything is fine but when you choose an >> existing issue, there is some 404 error and the Rietveld link is not adde

Re: git-cl upload and existing sf issues

On Sep 30, 2019, at 16:54, Malte Meyn wrote: > > when uploading a first patch set, git-cl asks for a sourceforge issue number. > If a new issue is created, everything is fine but when you choose an existing > issue, there is some 404 error and the Rietveld link is not added to the sf >

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

On Nov 1, 2019, at 02:52, Werner LEMBERG wrote: > >>> [...] because the `share' tree present in >>> >>> gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ >>> >>> is not created by the script in >>> >>> gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ >> >> This fixes the lilypond-test stage:

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > > Operand stack: > > (.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current/fonts/otf/emmentaler-20.otf) >(r) > Execution stack: [...] > Last OS error: No such file or directory > > because the `share' tree present in

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > > Operand stack: > > (.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current/fonts/otf/emmentaler-20.otf) >(r) > Execution stack: [...] > Last OS error: No such file or directory > > because the `share' tree

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > A good test for those things IMHO is to clone the gub repository, then > saying > > make lilypond I installed Ubuntu 19.10 on a spare computer, installed some necessary packages, cloned https://github.com/gperciva/gub.git, and ran "time make

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

On Oct 28, 2019, at 08:12, David Kastrup wrote: > >> I request some help to understand how I can improve my pre-commit >> testing procedures, and where my responsibilities begin and end. > > Responsibilities don't end. Fine. When a patch is submitted for review, there ends the opportunity to

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > Last OS error: No such file or directory > > because the `share' tree present in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ > > is not created by the script in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ > > I seem to

Re: make check is broken (again) - patch testing seeming to taking more of my time than I like

In the past month, I've devoted many hours to testing my submissions, but clearly the effort is not achieving the goal. I request some help to understand how I can improve my pre-commit testing procedures, and where my responsibilities begin and end. I enjoy having my commits reverted as much

Re: make test-redo

On Oct 14, 2019, at 21:59, Dan Eble wrote: > > On Oct 14, 2019, at 18:27, Carl Sorensen wrote: >> >> What is the defect you are seeing? The last time I tried it, it worked as >> described in the CG. > > I wiped my build directory and ran these commands with

Re: Issue 5583: www_post.py: don't mirror regtest baseline (issue 565170043 by nine.fierce.ball...@gmail.com)

> On Oct 23, 2019, at 12:36, David Kastrup wrote: > > "James Lowe" writes: > > Fixes should always be to staging rather than master but I guess that's > what you meant. It depends on just how old the problem is whether one > tries to hotfix it. Baselines created after this commit (a few

Regression test flip feature

Live demo: http://faithful.be/tmp/test-results Go to the images for rest-dot-position and press the "Flip" button under the right-hand image. The new image should change to the old image while the button is held. I've only tested it with the latest Safari for macOS, but I hope it works

Re: make test-redo

On Oct 14, 2019, at 18:27, Carl Sorensen wrote: > > What is the defect you are seeing? The last time I tried it, it worked as > described in the CG. I wiped my build directory and ran these commands with master @ fa6c70e39a. ../lilypond-src/autogen.sh make -j3 CPU_COUNT=3 make

make test-redo

"make test-redo" seems to be defective, so I’m thinking of removing it and simplifying the Contributor’s Guide. The last discussion I can find of it in the lilypond-devel archive is from 7 years ago, but I thought it would be good to ask if anyone here has used it successfully recently, just

make clean after mf changes

The Contributor’s Guide says, > Also, if you modify any font definitions in the mf/ directory then you must > run make clean and make before running make test-redo. This will recompile > everything, whether modified or not, and takes a lot longer. I assume the superficial explanation for

Re: make distclean now posts warning since commit b7532cf6e6d9

On Oct 13, 2019, at 04:11, James wrote: > > I get the following messages - that I never used to get - when I run a make > distclean > I checked out the previous commit (5674d4570d), wiped my build directory, ran autogen, and then this: make -j3 CPU_COUNT=3 test-baseline 2>&1 | tee

Re: lilypond does not work with Mac OS 10.15 (Catalina)

> On Oct 8, 2019, at 12:04, Dan Eble wrote: > > On Oct 8, 2019, at 11:09, Carl Sorensen wrote: >> Federico Bruno says the latest LilyDev includes a Docker container. >> http://lilypond.1069038.n5.nabble.com/LilyDev-0-3-released-td217945.html >> <http://lilypond

The behavior of "make check"

Begin forwarded message: > > Subject: [testlilyissues:issues] Re: #5564 Fix conversion warnings in beaming > code > Date: October 10, 2019 at 12:08:48 EDT > I'm sorry to contribute to your frustration. I can see what the process is, > but my question (which I direct to LilyPond developers in

Re: lilypond does not work with Mac OS 10.15 (Catalina)

On Oct 10, 2019, at 12:15, Hans Åberg wrote: > On 10 Oct 2019, at 17:55, Eric Benson wrote: >> >>> This is good, but I think GCC 8 was kept deliberately as it was unclear if >>> GCC 9 would work. >> >> gcc8 failed to build on MacPorts on Catalina on the latest Xcode. Rather >> than try to

Re: better LSR to lilypond snippet conversion tool

On Oct 8, 2019, at 16:21, Werner LEMBERG wrote: > I'm not sure how to proceed. Shall I adapt `makelsr.py' to start > where this script stops? I can't contribute much to an answer, but I want to say that the last time I tried updating snippets (probably over a year ago), the documented process

Re: lilypond does not work with Mac OS 10.15 (Catalina)

On Oct 8, 2019, at 11:09, Carl Sorensen wrote: > Federico Bruno says the latest LilyDev includes a Docker container. > http://lilypond.1069038.n5.nabble.com/LilyDev-0-3-released-td217945.html > FYI, I’m working on

Re: PATCHES - Countdown for October 8th

gt; > 5566 Update python headers to match surrounding files - masterodin > https://sourceforge.net/p/testlilyissues/issues/5566 > http://codereview.appspot.com/565080043 > > 5565 simplify python-related makefiles - Dan Eble > https://sourceforge.net/p/testlilyissues/issues/5565 >

Default make output

Who would cheer/object if I started working on changes to make the build output less verbose by default, which would require saying make VERBOSE=1 … when you actually wanted to see all the commands? By “less verbose,” I mean ideally logging one short line per interesting target at the

Re: Python 3

On Sep 30, 2019, at 19:46, Matthew Peveler wrote: > > I've been maintaining my work in > https://github.com/MasterOdin/lilypond/tree/py3_future2 > . . . > … but I do not know one would approach making it work on both Python 2 and > Python3.7 (and potentially other Python3 targets) and that I

Re: Python 3

On Sep 30, 2019, at 17:05, Matthew Peveler wrote: > > Please see attached for [ten] patches, which given the work done prior by > Jonas, allows for running the various make targets under both python2&3 > (assuming application of my other two patches for py3) The thought that gave rise to my

Re: Python 3

On Sep 30, 2019, at 14:22, David Kastrup wrote: > > But I don't see > that a clean cut from Python2 to Python3 in a single step is easily > feasible and testable for all targets at once including all GUB targets. OK. On Sep 27, 2019, at 16:34, Matthew Peveler wrote: > The primary thing

<    1   2   3   4   5   6   7   8   9   >