> Here is a patch that introduces a command line option aux-files,
> which can be used (-daux-files=#f, -dno-aux-files or #(ly:set-option
> 'no-aux-files)) to prevent lilypond's eps backend from creating
> .tex(i) and .count files:
>
> http://codereview.appspot.com/110107
>
> Okay to apply?
N
> Hmm. I've seen these errors for a long time now (maybe a year and a
> half), and I'm always using the latest fontforge tarball.
>
> Testing CVS, I get similar errors, first appearing with feta11:
Interesting. I haven't seen them since a long time. Please report
this to the FontForge list. H
>> While you are at it, please investigate why there are still
>> clipping problems during the EPS->PNG conversion. For an example,
>> look at the snappizzicato example image in the notation reference.
>
> The bounding box of the generated eps files is simply obtained from
> the scencil extents
> Here are my configuration settings for FontForge on a i586 GNU/Linux
> box: [...]
>
> --enable-double
IIRC, this option is the very one which makes the problems disappear.
Hmm. Perhaps it's better to write to the various distribution
packagers, urging them to compile FontForge wi
>>> Hmm. I currently can't imagine a situation where a value > 0 is
>>> needed, so I vote to remove the setting of
>>> #'outside-staff-priority for MultiMeasureRestText -- however, I'm
>>> not sure whether this has any influence to issue #495 (this looks
>>> rather unrelated to #'outside-staff-pr
> It seems sensible to have a distinct, lower, value, but something
> like 40 would place it below everything else while retaining some
> future flexibility.
OK. Shall I commit this or will you do that?
Werner
___
lilypond-devel mailing list
li
> Draft regtest and pdf output attached.
Thanks for your work!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> Jan proposed SCons [0], and after having read SCons User Manual, I
> think we could make good use of it. However, SCons has severe speed
> issues, which Waf [1], one of his younger (and Python-based, just
> like SCons) competitors, doesn't have -- see benchmarks [2] and [3].
Please have a look
> For the record (as discussed in private email), I'm quite concerned
> about waf's relative new-ness and occasional lack of development.
> My preference would be to use a stable, widely used build system,
> since any problems in the build system can cause a huge problem to
> developers. [...]
B
> Let's assume I've checked out a fresh master/origin and did some
> commits on top of it. How can I concatenate this commits in one to
> create only one patch?
Do
git reset ...
so that non of your changes are committed (`gitk' is your friend to
find the right SHA). Then do
git commit -a
> Ouch. so as soon as a LGPLv3 version of guile comes out, lilypond
> can't use guile any more, because LGPLv3 is not compatible with
> GPLv2... So, lilypond then has to switch to GPLv3... But then we
> have a problem with freetype, which is FTL (BSD with advertising
> clause, thus incompatible wi
What's the reason that line breaks are by default forbidden if there
is a broken beam crossing the bar line, and that you have to set the
`breakable' flag manually to override it?
BTW, it is very unpleasant that lilypond doesn't emit any kind of
warning if it produces an overlong staff caused by
I think something like the following patch should be applied so that
the \Dynamics context supports the `to-barline' property of hairpins.
However, I haven't tested whether it has any negative side effects.
Werner
==
---
>> What's the reason that line breaks are by default forbidden if
>> there is a broken beam crossing the bar line, and that you have to
>> set the `breakable' flag manually to override it?
>>
>> BTW, it is very unpleasant that lilypond doesn't emit any kind of
>> warning if it produces an overlong
> I *do* suspect there's a problem with the @lilyvindex macro, though.
I doubt that since I've basically duplicated code from texinfo.tex.
On the other hand, it is possible that the standard indexing macros
don't work well for non-ASCII stuff; this would indicate a generic
problem.
> But I can't
> @tex
> -\gdef\lilyvindex#1{\doind{vr}{\code #1}\ignorespaces}
> +\gdef\lilyvindex#1{\doind{vr}{\code{#1}}\ignorespaces}
> @end tex
Blush :-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/l
> -\gdef\lilyvindex#1{\doind{vr}{\code #1}\ignorespaces}
> +\gdef\lilyvindex#1{\doind{vr}{\code{#1}}\ignorespaces}
... and applied, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilyp
>> I've added a general event class, BreakSpanEvent, as the parent
>> class of BreakDynamicSpanEvent since I'd eventually like to
>> implement commands analogous to \breakDynamicSpan for some of the
>> other alignment spanners (e.g., pedals and figured bass).
>
> Awesome, thanks for your work, Ne
Ping!
Werner
==
From: Werner LEMBERG
Subject: support of `to-barline' property in \Dynamics
Date: Fri, 25 Sep 2009 21:06:18 +0200 (CEST)
> I think something like the following patch should be applied so th
Ping!
Werner
==
From: Werner LEMBERG
Subject: Re: line breaks and broken beams
Date: Sun, 27 Sep 2009 16:08:31 +0200 (CEST)
>
>>> What's the reason that line breaks are by default forbidden if
>
> Isn't the problem that beams create melismata in vocal music, and
> you don't want to have a line break in the middle of a melisma?
Hmm. How often does this happen in real scores? I think that in most
circumstances good (and thus flexible) spacing is much more important,
and a user should loc
> Would it be feasible to create new listeners/performers/contexts
> purely in Scheme, by having generic enough C++
> listener/performer/context factories that one can fit in everything
> worth having by using Scheme?
Well, there are ongoing efforts to move more functionality from C++ to
Scheme (
> I'm talking about developer tools. For example, some months ago I
> got the advice to use "grep" to browse LilyPond source code.
BTW, have you found something better?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.g
>>> I'm talking about developer tools. For example, some months ago I
>>> got the advice to use "grep" to browse LilyPond source code.
>>
>> BTW, have you found something better?
>>
> Eclipse is quite good at finding macro definitions etc., but it
> relies on some special build configuration, i mus
> Here is patch implementing the chord repetition shortcut that has been
> discussed a few times, [...]
Wonderful!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> Though strings are valid markup objects according to the type
> predicate `markup?', the parser only recognizes full_markup objects
> as valid for music functions, which means it's currently impossible
> to pass both strings and markups unless using Scheme.
>
> I've posted a modest patch here,
>> OTOH, something like
>> { 8-. -^ }*2
>>
>> is not doable with the q approach.
>
> Why not?
>
> \repeat unfold 2 { 8-. q-^ }
>
> Please stop trying to overload the * operator.
Well, David has a point here IMHO: The `\repeat unfold' really is
neither elegant nor intuitive nor quickly to type
> The rules are already defined (albeit unsatisfactorily in my opinion):
>
> Do whatever emacs does.
Then, for goodness' sake, why not write a small elisp program to use
Emacs in batch mode on the command line (yes, this is possible) to
format one or more files? Emacs runs on Windows too, and n
> Please review this patch:
>
> http://codereview.appspot.com/152127/show
Very nice!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[using cc-mode for automatically formatting C++ code of lilypond]
>> IIRC, you mentioned this before; I think it's to do with (your)
>> emacs expecting a colon at the end of the macro (which isn't
>> strictly necessary).
>
> D'oh. I mean semicolon of course. :)
In case we are going to automatic
>> I don't think that I can contribute much more to your amusement.
>
> Wow.
> I've [fortunately] never witnessed such mindless negative energy on
> a mailing list to which I've been subscribed.
Guys, cool down. I think everyone of you is interested to improve
lilypond, perhaps it helps if all
Please see #924.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
It seems that the algorithm for optimal page turning is designed for
recto and verso pages. In other words, the `first-page-number' paper
variable is also an important parameter controlling the layout.
Is this correct? However, it is mentioned nowhere.
Werner
___
See issue #926. This makes the Dynamics context quite useless.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> I was amused by the recent "punctuation fix" commit: [...]
BTW, may I remind to have TWO spaces after a full stop, exclamation
mark and question mark at the end of a sentence. This is both useful
for certain editors (like Emacs), and it helps the text-mode info
browser to break lines.
IIRC, th
>> BTW, may I remind to have TWO spaces after a full stop, exclamation
>> mark and question mark at the end of a sentence.
>
> That is the practice I recall from my time typing others doctoral
> thesi. Sadly it is not the norm for html or many modern
> text-setting applications which ruthlessly t
Graham,
is it correct that all fixes, regardless of its annoyance, get a `low
priority' in case it won't become part of the next `milestone'
release?
I consider this categorization a bit coarse, and I would like to see
at least one more level to mark bugs as `annoying' or something like
that.
> If you'd entered them yourself as both Medium, or both
> Low, I wouldn't have said anything.
OK.
> - Low: the normal priority. Sorry, but we just don't have many bug
> fixers! I favor honesty over trying to make users happy about
> assigning their pet issue a "higher priority" flag that
> If you would like to change the priority between postponed, low, and
> medium issues -- either raising the priority of a postponed or low
> one, or lowering the priority of a low or medium one -- go ahead.
I'll eventually do that for my own bugs. However, it's basically the
job of the bugmeist
> 1. Severity of the Bug.
> 2. Probability of occurrence of the bug.
> 3. Difficulty of working around.
Very nice!
> Of course, I'm not proposing that anybody stop fixing bugs in order
> to perform this calculation. I just wanted to get the thought in
> this thread in case we ever want to serio
>> See issue #926. This makes the Dynamics context quite useless.
>
> Fixed in git.
Thanks!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks to Neil, TextSpanner items are now displayed in `Dynamics'
contexts. However, this exhibits another serious annoyance, as shown
in bug issue #928.
This time, I've tagged my bug report with `medium'...
Werner
___
lilypond-devel mailing li
Could someone please check issue #774 with a stable release (either
2.10 or 2.12) so that I can probably set the regression flag? At the
time of my report, I only had 2.11.13 for comparison, which is a
developer's version, and I still don't have any stable releases
installed.
Werner
_
>> Could someone please check issue #774 with a stable release (either
>> 2.10 or 2.12) so that I can probably set the regression flag? At
>> the time of my report, I only had 2.11.13 for comparison, which is
>> a developer's version, and I still don't have any stable releases
>> installed.
>
>
Neil,
have you finished your work on fixing #305? I can vaguely remember
something into this direction ...
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> Two options:
>
> %% The second upper "c" octave is computed from the first "c"
> %% i.e. the last explicite note.
> \relative c' {
> 8 c' q c r4 q
> }
>
> %% The second upper "c" octave is computed from the previous
> %% repeated chord ("q")
> \relative c' {
> 8 c' q c' r4 q
> }
>
> I'd fa
> So I'd think it would be nice to write something like
>
> { G4 g D // | // // | \time 3/4 G g / | D // / | // // / | }
>
> (number of slashes corresponds with how far you have to look
> backwards, in this case counting slash sequences new when they
> appear) or without reslash mem
> * Because the build happens inside a container, we can test multiple
> builds. We could build against guile 1.8 and 2.2 at the same time,
> for example.
I have zero experience with docker, but your suggestions sound quite
interesting!
Regarding image comparison: The Chromium team uses Free
> Werner basically is the person most affected by changes I have not
> yet cherry-picked because of problems, changes that likely would be
> a good idea to have in 2.20.
>
> Those are his extensive indexing review, and reworks of several
> examples. The indexing review is hard to apply to the by
>> I could try to cherry-pick my own patches into 2.20 – this is, I
>> prepare a set of commits and send them to you for further testing.
>> Does this sound reasonable?
>
> I'll just pick the examples, they will likely go quite clean.
OK.
> But if you think about what you want to do about the i
> Теноры
> Very odd - I've just installed a CMU font and it's got all the
> Russian alphabet.
What exactly do you mean with 'installing'? I'm talking about the
creation of PDF files using xelatex, using only standardized fonts
(this is, avoiding fonts that are accidentally present on your
syste
>> However, I'd like to hear from David Kastrup and James Lowe
>> first. To me, their opposition registered as the strongest.
>
> I remain strongly opposed to a CoC.
Hmm. What about simply using the GNU Kind Communication Guidelines,
maybe adding 'LilyPond' at some strategic places?
Wern
>>> See the line above which is in CMU Concrete!
>
>> ??? I use Emacs to read my e-mail, and emacs is configured to use
>> the font 'DejaVu Sans Mono' on my GNU/Linux box. This font
>> contains Cyrillic glyphs...
>
> I composed that line in the email using CMU Concrete. Presumably
> your emai
Snipped 446 ('Modifying default values for articulation shorthand
notation') still talks about 'dashBar', which has been replaced by
'dashBang' in 2013.
Please fix. Alternatively, please make me (user 'lemzwerg' on LSR) an
editor so that I can do it myself :-)
Werner
>> Please all take a look and let me know what you think!
>
> For a first pitch certainly impressive. It's nice that the SHA1 ids
> have become live.
+1 Very nice!
Werner
It seems that the recent version of 'gettext' (0.21 from Dec. 2019) on
MacOS – at least on my Lion box – has changed language handling. In
the NEWS file I read
* Runtime behaviour:
- The interpretation of the language preferences on macOS has been
improved, especially in the case whe
For fun I tried to execute
https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83/2.19.83.build20200207173449
on my old MacOS Lion box, with the following error.
Traceback (most recent call last):
File ".../LilyPond 2.app/Contents/Resources/__boot__.py", line 98, in
_r
>> LilyPond Error
>
> Does it ship with Python, or using the native? The 2.19.83 from the
> site uses 2.6, not 2.7.
> python --version
Python 2.7.17
Werner
> The download size for the notation manual comes out at 35MB which is
> about double than what we had for 2.16. I actually find that
> somewhat irritating. I'd have to check the old conversations about
> extractpdfmark and see whether this is indeed where our change of
> text fonts would have p
> I think the download text would warrant correction.
Yes.
> I just naively assumed it to be automatically generated in
> correspondence with reality.
This is an excellent suggestion. Not sure how to implement that
easily, but please open a tracker issue so that the idea is not lost.
We
Some time ago I was asked to document how to prepare MWE for reporting
FontForge problems with Emmentaler. Here it is.
How to report `FontForge` problems while creating LilyPond fonts
The output produced by the `mf2pt1` script t
Folks,
something that can be easily missed while doing reviews with Rietveld:
Since a long time we avoid tabs if possible.
Werner
PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
branch.
PPS: I see that we have a file `.dir-locals.el` in the git repository;
d
What do you think about converting all tabs in the .mf files to
spaces? If you agree, I would apply this to the staging.
Werner
>> PPS: I see that we have a file `.dir-locals.el` in the git
>> repository; doesn't its contents contradict our tabs policy?
>
> No, it implements it.
Ah, ok. Thanks for the explanation.
> Yes, does not read well to human readers. Maybe one should tack on
> the redundant . nil here, but
> /usr/bin/ld: final link failed: No space left on device
This looks suspicious. Have you verified that you have enough free
disk space?
Werner
> I know it says
>
> /usr/bin/ld: final link failed: No space left on device
> collect2: error: ld returned 1 exit status
>
> but I have plenty. I moved the build dir to a place I know I have
> plenty of space (just to be sure) and still get the same problem.
>
> Could this be some permission is
>> PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
>> branch.
>
> Ugh, that's giving me a nice set of conflicts.
Sorry for that.
Werner
>> 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 e
> 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 bl
>> 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
> Unfortunately, mf overlaps can hardly be avoided in many cases,
> because lots of glyphs are being composed out of several overlapping
> predefined components.
Yes, and avoiding overlaps everywhere would lead to unnecessarily
complicated code. Tools like FontForge should be used to fix this i
> I'll open up a ticket and upload a patch as soon as it's finished
> (it already works, but I want a proper solution).
Great, thanks!
> *By the way:* how about TABs? Obviously, gitk, Rietveld et al. seem
> to use 8 spaces per tab.
I've just committed a patch that converts tabs to spaces in al
> how do I set LOCALEDIR (in this case, to match the packaged app
> bundle rather than the build-time path)? Unlike everything else of
> this nature, neither the .reloc files nor environment variables work
> (and I've tried setting both LOCALEDIR and LILYPOND_LOCALEDIR in
> both places): when I u
use that setting, or do only
> the child programs use it?
Please try the attached patch. It now calls `bindtextdomain` a third
time to take care of setting `LILYPOND_LOCALEDIR` in the relocation
files.
Werner
>From fb1c6fea888450974eafc0b31add9a2d926d0106 Mon Sep 17 00:00:00 2001
Fro
>> Please try the attached patch. It now calls `bindtextdomain` a
>> third time to take care of setting `LILYPOND_LOCALEDIR` in the
>> relocation files.
>
> I’d really rather not patch the code if I don’t have to, and three
> attempts to do anything seems smelly to me (it suggests that the
> logi
>> I don't think that the logic flow is wrong. The idea is to have
>> translated error and warning messages as soon as possible. At the
>> very beginning, lilypond only knows about the compile-time
>> LOCALEDIR location. Later on it checks the LILYPOND_LOCALEDIR
>> environment variable, and fin
> [A suggestion: you may want to keep attributions when trimming
> quotes.]
What exactly do you mean?
>> Let's assume that a user sets the LILYPOND_LOCALEDIR environment
>> variable manually for experimental purposes but not in the
>> relocation files. To get translated messages early it makes
> From: Marnen Laibow-Koser
>
> I mean that it’s clearer who wrote what if you don’t delete the line
> that says “Werner LEMBERG wrote:” :)
Ah, my mailer doesn't generate that.
>> IMHO, environment variables should be handled as being 'stronger'
>> than
> From: Marnen Laibow-Koser
> Date: Wed, 4 Mar 2020 10:35:00 -0500
>
>> The search algorithm is actually documented in `usage.pdf`,
>
> I’ve never seen that file. Where would I find it?
Ouch. It should be at
http://lilypond.org/doc/v2.19/Documentation/usage-big-page.html#relocation
but it'
>> OMG this is documented? I wish I’d known all this weeks ago when I
>> was writing the Mac Makefile!
FYI, here is the first part of the relocation documentation.
There’s actually a second mechanism for run-time configuration:
LilyPond heavily relies on external programs and libraries, in
> The mentioned commit 7200d7365be was after stable/2.20 was branched
> and not backported AFAICS. This means both 2.19.84 and 2.20.0 use
> the "old" relocation algorithm that was not documented. So the
> files at lilypond.org are correct, even if that's maybe unfortunate
> in this case. This
> In addition, PKG_CONFIG_PATH is not documented in our configuration
> or with ./configure --help.
>
> How to fix?
I will take care of this. Reason is that in calls to `PKG_...`,
`configure.ac` often uses the explicit argument `true`, which prevents
the creation of default actions. For exampl
>> and all of those messages are auto-generated.
>
> So? This does not provide a documented way of getting Guile
> activated at all unless you are a 14th level system building
> magician.
I'll try to update the documentation, too.
> So the correct way is to continue _heeding_ GUILE_CONFIG whe
> For example, FreeType's `configure --help` output produces
>
> ...
> PKG_CONFIG path to pkg-config utility
> PKG_CONFIG_PATH
> directories to add to pkg-config's search path
> PKG_CONFIG_LIBDIR
> path overriding pkg-config's built-in search path
> LT_SYS_
>>> Is there anybody who recently built with a non-system version of
>>> Guile-1.8 intentionally?
>>
>> I do this all the time.
>
> So how did you do it last week?
I updated my build script, see below. Note that I install texi2html
1.82 and guile 1.8.8 in `/uar/local/opt`.
>> Usually, I try to
In standard GNU projects, the `aclocal.m4` file gets auto-generated
with the `aclocal` script; the necessary M4 scripts are either taken
from the system or from a directory that gets specified with some
command line options to `aclocal`.
Looking into the git history of LilyPond's `aclocal.m4` fi
Folks,
I can use `git-cl` just fine. However, I always get the message
Problem setting patch status for Allura issue
and the 'owner' field of the created SF issue is not properly set.
Any idea how to fix this?
Werner
>> I suggest to use `aclocal` again, modularizing the current stuff in
>> `aclocal.m4` by splitting it into various `.m4` files in a `m4`
>> top-level subdirectory.
>
> +1 for doing this, but this is a very low-level tooling change. I'm
> in favor of doing 2.21.0 first.
OK. Add as issue #5831
>> As I said: I believe the proper action is to make LilyPond's
>> `configure` script emit a warning if it finds GUILE_CONFIG set.
>
> I disagree: Why do we have to keep everything compatible for a new
> *major* release like it used to be in the past? That's very
> prohibitive of any substantia
>> I updated my build script, see below.
>
> How did you notice that you had to?
Since I don't have guile 2.x installed the problem was immediately
visible.
>> Note that I install texi2html 1.82 and guile 1.8.8 in
>> `/uar/local/opt`.
>
> So what do you do if you also have guile-2.2 and guile
> I have no beef with deprecating it.
What about the following route? For guile, I would add support for
`guile-config`, using the following algorithm (with item 1 already
implemented).
1. Search for a guile `.pc` file, checking whether version 1.8.x,
2.2.x, or 2.0.x is present (in this or
>> > > > The following prints an error and directs the integrators
>> > > > into the right direction:
>> > > >
>> > > > diff --git a/configure.ac b/configure.ac
>> > > > index 29e4e5680f..80a34f7b09 100644
>> > > > --- a/configure.ac
>> > > > +++ b/configure.ac
>> > > > @@ -189,6 +189,11 @@ STEPM
> Not being able to change gradually makes development more painful.
> There was discussion as to why there are so few developers - this
> will be my prime reason if I'm required to add compatibility for
> everything. Yes, this includes things so fundamental as Guile.
Uh, oh, now you are exagge
> I think a safe step right now is for Werner to update the upstream
> pkgconfig autoconf support. Whatever we end up with, there is no
> point in designing a solution that does not involve that as a
> component. I wanted to suggest him fast-tracking that change
> separately because of that.
D
> Is everyone fine with me pushing such fixes directly to staging? I'm
> not very happy that we're hitting this with infrequently run scripts
> only now 😞
+1
Werner
Folks,
three questions regarding the LSR.
(1) Will the PNG images shown in the LSR automatically be regenerated
if a snippet gets updated? Or do I have to do something?
(2) Will the LSR be re-imported into the LilyPond git repository
before the 2.21 release?
(3) When will the LSR be
Hello Harm,
thanks for the answers.
>> (2) Will the LSR be re-imported into the LilyPond git repository
>> before the 2.21 release?
>
> Someone has to do it, if this is wished.
I think this would be beneficial. David?
>> (3) When will the LSR be updated to use LilyPond 2.20?
>
> Iirc,
> The INSTALL.txt text should reflect the current situation, not
> future ones. So it is more like
>
> libguile 2.x is getting used if no installation of 1.8.8 is
> found during configuration. However, matching the reliability
> and performance of LilyPond when using libguile 1.8.8
> I've fixed it in LSR by reordering engravers.
> http://lsr.di.unimi.it/LSR/Item?id=506
Great!
> Werner, seems said snippet is based on your idea. Could you have a
> look, if the output is now as wished again?
I would remove the second, redundant 6/4 in the viola voice.
Werner
>> What's the motivation to use Python for all of this?
>
> What's the motivation to use sh for all this?
>
> You can certainly make it shorter with shell, but will it be
> significantly simpler, easier to understand or easier to maintain?
>
> I decided for Python in this case, because recursion se
201 - 300 of 3488 matches
Mail list logo
