Re: define-void-function or define-procedure ?
Carl Sorensen c_soren...@byu.edu writes:
On 10/19/11 3:14 PM, David Kastrup d...@gnu.org wrote:
I am not enthused about this particular consequence of
auto-exporting Scheme expressions. I currently don't see a better
way of handling it, and it has flagged more bad code than false
positives when I tried it. But I would be quite surprised if it did
not trigger regressions with existing previously valid and
reasonable code.
I think if we're finding bad code, it's probably an improvement. But
to the extent that we break valid code, it's a problem.
previously valid. But of course any change that non-trivially changes
rather than _merely_ extends functionality needs quite more
consideration. Most of my changes so far I have been able to just sneak
in under the radar because they would only affect fringe code
negatively, code that nobody writes.
An afterthought, however: we do have an inordinate amount of
user-level commands that need to be called from Scheme rather than
with Lilypond syntax. That does not make sense. Void music functions
have been around for eternities, just a bit inconvenient to define,
but reasonably documented.
I think that there has been some feeling in the past that defining
void functions and using lilypond mode to handle these commands is
just syntactic sugar.
I quite disagree since Lilypond functions have type-checked arguments
and work fine with convert-ly. convert-ly does not touch Scheme code,
and so Scheme code can be reasonably considered to be effectively not
part of the language.
Now of course my current project is trying to break the barriers between
Scheme and Lilypond mode, but my main motivation is that people can
avoid having to use Scheme for a whole task that is 95% doable in
Lilypond. If you can just squeeze the required 5% of Scheme into
Lilypond constructs not specifically designed for that, the amount of
Scheme knowledge you need before being able to do something useful is
much less. And the probability of your code being able to survive
convert-ly passes with correct results increases.
One I want to do that eventually project of mine is to have #{ ... #}
parsed at compile time so that no motivation for using (markup ...) over
#{ \markup { ... } #} remains. For user level code, I consider the
second choice quite preferable already.
Perhaps one good idea would be to have all music functions be trivially
callable in Scheme. That way, arguments would get typechecked, and
there would be no compatibility excuses for not providing music
functions. Old code would continue working without convert-ly hassles,
but one would change the implementation and rip out the old docs right
away.
The one thing needing consideration are the parser location args since
they might get used for syntax errors and #{ ... #}. So either they
need to be required parts of the function signature, or the boilerplate
checking the arguments and rerouting the call picks them from the
context of the calling #(...) construct or from the environment of the
music function definition, if all else fails.
Or one does not provide a pure Scheme wrapper for any function that
actually uses parser and location. Not sure whether one can wheedle
this information from Guile.
Maybe we need a user interface meister that tries to maintain a bit of
coherency and sanity when new features get added.
It seems to me that you are functioning as the UI meister right now.
Not really. I am tearing my hairs and providing infrastructure mostly,
but not actually interfering significantly with existing interfaces.
I won't be able to root out all existing bad examples to a degree where
newcomers will feel bad about providing awkward code.
So my focus is on trying to make it easy to do better. Most people are
happy when the thing they have been concocting is able to do the job for
them. So it needs to be easy, hopefully a total no-brainer, to do it
nice on first try.
So I am not acting as much as UI meister, but rather trying to be a good
UI manager in the sense that a good manager is one that manages not
having to manage things.
A UI meister would exercise authority, tell people not to do bad things.
I try making it hard to do bad things even without a UI meister
exercising his iron grip. And once it is hard enough, I shout and
holler and stomp my feet without bad conscience. When I get to see bad
things. But most of the time I am too lazy to pay attention.
And you're doing a great job of it -- not just trying to get new
interfaces to be sane, but pointing out where there is insanity in the
existing interfaces.
Drive-by shootings.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 2011/10/20 04:06:03, Keith wrote: Neil, don't forget to push this. I've been looking forward to it. I'll try to sort it out at the weekend. Unfortunately I don't have a working Linux install at the moment, and foolishly neglected to back it up for easier restoring. Cheers, Neil http://codereview.appspot.com/4819064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
On 2011/10/20 05:44:38, dak wrote: Sorry, I always start thinking only when far too late in the game. Anyway, here is a musing: should't the _main_ interface to accidental modifications be context mods? You won't need to set them in midcontext except in unusual situations, and then \applyContext (?) is available. That would be possible, though you'd probably want a nicer interface than using \applyContext directly. A music function would have to have two args: the optional context string and the context-mod identifier. Cheers, Neil http://codereview.appspot.com/4819064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On 11-10-19 10:42 PM, Graham Percival wrote: On Wed, Oct 19, 2011 at 10:00:26PM -0600, Colin Campbell wrote: Command barfed: cd /home/colin/gub/target/tools/build/curl-7.19.0 make -j4 Tail of target/tools/log/curl.log make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/colin/gub/target/tools/build/curl-7.19.0/src' make: *** [all-recursive] Error 1 Command barfed: cd /home/colin/gub/target/tools/build/curl-7.19.0 make -j4 Tail of target/tools/log/curl.log Well, what do you see in target/tools/log/curl.log ? The portion of that logfile that GUB showed you doesn't contain any useful info, so please manually open up that logfile and look for anything suspicious. also, exactly what OS/hardware are you using? By chance I started working on the recompile everything issue earlier tonight, and curl built on my lilydev ubuntu machine. Cheers, - Graham The error seems to be just above the tailed part: libtool: link: gcc -I/home/colin/gub/target/tools/root/usr/include -Wl,-rpath -Wl,\$ORIGIN/../lib -Wl,-rpath -Wl,/home/colin/gub/target/tools/root/usr/lib -o .libs/curl main.o hugehelp.o urlglob.o writeout.o writeenv.o getpass.o homedir.o curlutil.o strtoofft.o strdup.o -L/home/colin/gub/target/tools/root/usr/lib ../lib/.libs/libcurl.so -lidn -lldap -lrt -lssl -lcrypto -lz ../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method' collect2: ld returned 1 exit status make[2]: *** [curl] Error 1 make[2]: Leaving directory `/home/colin/gub/target/tools/build/curl-7.19.0/src' I tried a git grep SSLv2_client_method but got nothing. This is on Ubuntu 11.10 on an x86-64 machine, running natively. I'll try my VM 32-bit Ubuntu at the office later today. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Sketch for in-notes. (issue 5293053)
Reviewers: ,
Message:
Hey all,
As part of project markup at the suggestion of Nicolas Sceaux by way
of Valentin's opera, I've implemented in-notes in LilyPond. These notes
hover above systems and come up a fair bit in vocal music.
It works, but I have one major and one semi-major snag that I'd like to
run by people. Please don't run the regtests on this yet until these
snags are worked out.
Semi-major-snag: get_footnotes_from_lines should only ever be called
once and should stash its results in the systems and/or probs. I'll
figure out how to do this in the near future.
Major snag. On about 1 out of every 5 runs of this patch, it leads to
way-too-big spacing. This is because the stencils of in notes are, for
some reason, registering infinite extents in page-spacing.cc when
they're being counted (check account_for_footnotes and you'll see that
the value of the extent for in_notes is occasionally really really
really large). This is strange because when the in_notes are added to
the breaker (System::get_in_notes_in_range), these extents are correct.
I think it is an issue with pointers and garbage collection of stencils
- does anyone have any intuition about this.
Here's a test file:
\version 2.15.15
\header {
texidoc = LilyPond does in-notes. The positioning of these notes can
be above or below the staff via the paper variable @code{in note
direction}
and spaced via the variable @{in-note-padding}.
}
\relative c' {
\repeat unfold 5 {
\repeat unfold 20 { a\ b c d\! }
% activates the in-note
\once \override FootnoteItem #'footnote = ##f
\footnoteGrob #'NoteHead #'(0 . 0)
\markup { \box \fill-line { this is a test this is
a test } }
a b c d
\repeat unfold 20 { a b c d }
\autoFootnoteGrob #'NoteHead #'(-1 . 1) foo bar foo bar
a b c d
\repeat unfold 20 { a\ b c d\! }
}
}
Description:
Sketch for in-notes.
Please review this at http://codereview.appspot.com/5293053/
Affected files:
M lily/constrained-breaking.cc
M lily/include/constrained-breaking.hh
M lily/include/page-breaking.hh
M lily/include/page-layout-problem.hh
M lily/include/system.hh
M lily/page-breaking.cc
M lily/page-layout-problem.cc
M lily/page-spacing.cc
M lily/system.cc
M scm/define-grob-interfaces.scm
M scm/define-grob-properties.scm
M scm/define-grobs.scm
M scm/paper-system.scm
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for in-notes. (issue 5293053)
The memory management issue is now fixed. A new patch will be coming down the pipe in 2-3 hours with a regtest. Cheers, MS http://codereview.appspot.com/5293053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: How do feel people about the following change in syntax?
David Kastrup d...@gnu.org writes: Now here is one thing worth considering: currently the predicate scheme? is defined as (define-public (scheme? x) #t) I lean towards defining it instead as (define-public (scheme? x) (not (eq? x (begin so that it will accept anything _except_ void expressions. Does that appear like a good idea? Ugh, it means that define-void-function can't be a special case of define-scheme-function: define-void-function will always return a void expression, and define-scheme-function is defined to return a value of type scheme?, so Lilypond would protest if you tried to return a void expression and probably return #f after flagging an error. define-scheme-function is pretty young, so perhaps disallowing it from returning void expressions makes some sense without all too much compatibility pain as long as define-void-function is available for functions not returning anything. Is it ok if I do this as one commit series? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for in-notes. (issue 5293053)
Hey all, The patch is now ready to be tested - I got a clean bill of health from the regtests. Cheers, MS http://codereview.appspot.com/5293053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On Thu, Oct 20, 2011 at 07:05:54AM -0600, Colin Campbell wrote: ../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method' collect2: ld returned 1 exit status I tried a git grep SSLv2_client_method but got nothing. Try this: sudo apt-get install libssl-dev then try the bootstrap again If that works, I'll add it to the dependencies listed in the README. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sketch for broken beams with consistent slopes (issue 4961041)
http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely
File Documentation/changes.tely (right):
http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode66
Documentation/changes.tely:66: \override Beam #'breakable = ##t
no indent
http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode68
Documentation/changes.tely:68: a8 [ b c d e f g \bar \break f e d c b
a ]
a8[
a]
http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode78
Documentation/changes.tely:78: the beam grob. All Scheme functions that
used these callbacks are now
two spaces after full stop/period
http://codereview.appspot.com/4961041/diff/60001/Documentation/changes.tely#newcode79
Documentation/changes.tely:79: simplified. For examples, see
@file{input/regression/beam-concave.ly}
You shouldn't reference regression tests here. Will frighten users. :)
http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly
File input/regression/beam-consistent-broken-slope.ly (right):
http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly#newcode2
input/regression/beam-consistent-broken-slope.ly:2: \version 2.15.12
2.15.15
http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly#newcode12
input/regression/beam-consistent-broken-slope.ly:12: \override Beam
#'breakable = ##t
indent, code style
http://codereview.appspot.com/4961041/diff/60001/input/regression/beam-consistent-broken-slope.ly#newcode13
input/regression/beam-consistent-broken-slope.ly:13: a8 [ b c d e f g
\bar \break f e d c b a ]
a8[
a]
etc.
http://codereview.appspot.com/4961041/diff/60001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/4961041/diff/60001/scm/define-grob-properties.scm#newcode749
scm/define-grob-properties.scm:749: (skip-quanting ,boolean? Should
beam quanting be skipped?)
Is this likely to be used outside regression testing?
http://codereview.appspot.com/4961041/diff/60001/scm/define-grobs.scm
File scm/define-grobs.scm (right):
http://codereview.appspot.com/4961041/diff/60001/scm/define-grobs.scm#newcode386
scm/define-grobs.scm:386: (positions . ,ly:beam::quanting)
remove extra space
http://codereview.appspot.com/4961041/diff/60001/scm/layout-beam.scm
File scm/layout-beam.scm (right):
http://codereview.appspot.com/4961041/diff/60001/scm/layout-beam.scm#newcode65
scm/layout-beam.scm:65: grob
indent
http://codereview.appspot.com/4961041/diff/60001/scm/layout-beam.scm#newcode72
scm/layout-beam.scm:72: grob
indent
http://codereview.appspot.com/4961041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
On 11-10-20 12:29 PM, Graham Percival wrote: On Thu, Oct 20, 2011 at 07:05:54AM -0600, Colin Campbell wrote: ../lib/.libs/libcurl.so: undefined reference to `SSLv2_client_method' collect2: ld returned 1 exit status I tried a git grep SSLv2_client_method but got nothing. Try this: sudo apt-get install libssl-dev then try the bootstrap again If that works, I'll add it to the dependencies listed in the README. Cheers, - Graham I already had it installed (version 1.0.0e-2ubuntu4 FWIW). Cheers Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: First stab at getting script offsets right. (issue 5235052)
LGTM, but the result is really disturbing. We need to think about a better approach of character boxes in MetaFont. The ideal solution would be to create a mask for each character. For example, a mask for the espressivo glyph would be a fill between its 6 dots. I know it's impossible to interpret this mask in C++... Anyway, I think this patch can be pushed as the first part of a fix to issue 1951. Bertrand http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc File lily/script-engraver.cc (right): http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc#newcode208 lily/script-engraver.cc:208: int script_count = scripts_.size (); vsize instead of int. Could you change the others above? http://codereview.appspot.com/5235052/diff/23001/lily/script-engraver.cc#newcode209 lily/script-engraver.cc:209: for (int i = 0; i script_count; i++) vsize. http://codereview.appspot.com/5235052/diff/23001/lily/slur.cc File lily/slur.cc (right): http://codereview.appspot.com/5235052/diff/23001/lily/slur.cc#newcode275 lily/slur.cc:275: // cannot use is empty because some 0-extent scripts I don't understand. Did you meant if empty? http://codereview.appspot.com/5235052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20111023
For 22:00 MDT Sunday October 23 Issue 1506 http://code.google.com/p/lilypond/issues/detail?id=1506: \tempo after StopStaff/StartStaff forces extension of staff symbol - R 5303043 http://codereview.appspot.com/5303043/ Issue 1663 http://code.google.com/p/lilypond/issues/detail?id=1663: Images missing on web site - R 5276054 http://codereview.appspot.com/5276054/ Issue 1951 http://code.google.com/p/lilypond/issues/detail?id=1951: Scripts collide with accidentals - R 5235052 http://codereview.appspot.com/5235052/ Issue 1979 http://code.google.com/p/lilypond/issues/detail?id=1979: Patch: convert-ly rules for Stem \#'stencil = \#\#f - R 5316041 http://codereview.appspot.com/5316041/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
