denly" (I had a hope to do "everything undone so far",
but now I am unable, really) -- please, be lenient.
Thank you!
On Sat 29 Oct 2011, 05:42 Graham Percival wrote:
> On Fri, Oct 28, 2011 at 04:51:33PM +0300, Dmytro O. Redchuk wrote:
> > On Fri 28 Oct 2011, 14:44 Phi
need it?
Should we require these labels be assigned?
--
Dmytro O. Redchuk"Easy to use" is easy to say.
Bug Squad -- Jeff Garbers
___
lilypond-devel mailing list
e require such labels or not. Do anyone need to have them?
ps. Yes, I am rather "inactive" last two weeks. I am sorry. Probably I should
decide where to move next months.
> We can get into real problems when programmers assume that they've
> fixed something when they haven
open eps
> files in Lilydev so all regtest archives from
> http://lilypond.org/download/binaries/test-output/ are useless for
> me...
I've finally added this as 1918:
http://code.google.com/p/lilypond/issues/detail?id=1918
Please, anyone, help me adjust labels.
--
Dmytro O. Redch
eplace that with a png.
Dmytro?-)
Here is it:
https://raw.github.com/gperciva/lilypond-extra/master/bug-squad/trimtagline.sh
https://raw.github.com/gperciva/lilypond-extra/master/bug-squad/trimtagline.bat
--
Dmytro O. Redchuk"Easy to use&q
(cons my-down my-up
>
> {
> c''_\fermata
> \override Stem #'Y-extent = #'(-10 . 0)
> \override Stem #'stencil = #my-stem
> c''_\fermata
> }
>
> I'm not sure of a good way to deal with this from a UI perspective,
rob "to have no extent". But it didn't change
grob's appearance.
Sorry my jumping in though. Very probably, I've missed something important.
--
Dmytro O. Redchuk"Easy to use" is easy to say.
Bug Squad
;s a stupid example, but it's quite good that 'length and 'Y-extent can
do _different_ things.
begin - end = extent -- isn't it "simply default value" for extent?
--
Dmytro O. Redchuk"Easy to use" is easy to say.
Bug Squad
ussed a bit in lists?
--
Dmytro O. Redchuk"Easy to use" is easy to say.
Bug Squad -- Jeff Garbers
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu
is not clear what the
> correct output should look like. We need scans, references,
> examples, etc.
No type-documentation any more? Why? Sorry, I've jumped a bit late thought.
I agree that we can classify work with tags/labels; however things like docs
improv
t; Perhaps more diplomatically as "Type- ambiguous"?
type-pendinginput?
--
Dmytro O. Redchuk"Easy to use" is easy to say.
Bug Squad -- Jeff Garbers
___
lil
someone can edit the summary and fill it in? I don't
> have permissions (or maybe it is not possible).
done.
>
> James
Thank you.
--
Dmytro O. Redchuk"Easy to use" is easy to say.
Bug Squad
r release, as is. It distills the problem a little more -- at
> the expense of centering the number directly on the beam . . .
>
> I hope that in some way this is useful :)
I've added this as 1745:
http://code.google.com/p/lilypond/issues/detail?id=1745
Thank you!
--
t; Cheers,
> Xavier
>
> --
> Xavier Scheuer
>
> ___
> bug-lilypond mailing list
> bug-lilyp...@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
them there myself. No rush, though.
Yes, I will play. I've already forked. Great place to keep work at.
Thanks!
Some time I will issue pull request; later; now I will just play.
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
l
er,)
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
a-natural should either be killed or made
> slightly longer.
>
> It prints fine w/o the accidental on the f:
>
> {1 ~ \break 1 }
This _exactly_ the same picture as above (well, yes, the tie is a very little
bit longer thought).
--
rings in some argument
> >> # functions, and refuse them in some other places
> > This is related to at least 1054 and 1073, by the way.
>
> Do you know how to prevent this to happen?
Actually no, i don't. Sorry.
--
Dmytro O. Redchuk
Bug Squad
# ugh, Python 2.5 optparse requires Unicode strings in some argument
> # functions, and refuse them in some other places
This is related to at least 1054 and 1073, by the way.
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
snip---
> >
> > Gives the following error in the log
>
> Bug Squad: priority-critical, type-build.
Done:
http://code.google.com/p/lilypond/issues/detail?id=1562
>
> Cheers,
> - Graham
--
Dmytro O. Redchuk
Bug Squad
___
li
ot; }
>
> \relative c' {
> e'8[ f e \grace { f,16[ a] } e'8]
> }
For the record:
This is reported as 795 and is being under discussion and development right
now, as far as i know.
--
Dmytro O. Redchuk
Bug Squad
___
gs will take care of it:
> [ /Author string
> /Title string
> /Subject string
> /Keywords string
> /DOCINFO pdfmark
Added as 1463:
http://code.google.com/p/lilypond/issues/detail?id=1463
Thank you.
--
Dmytro O. Redchuk
Bug Squad
___
quot;if i will not be corrected -- so, it's not a
problem".
Because i think that discussing a rule (what is "minor elements", what is
"many times", "complex situation" etc) and explaining it to new bugsquadders
(or reviewers, or whoever) can waste some time
On Tue 14 Dec 2010, 15:12 Trevor Daniels wrote:
> Carl Sorensen wrote Tuesday, December 14, 2010 12:55 PM
> >
> >On Dec 14, 2010, at 5:45 AM, "Dmytro O. Redchuk"
> > wrote:
> >
> >>I fail to see why this test (accidental.ly) would be less
> &g
d miss an error
> elsewhere.
I would agree.
Well, i was trying to remember what is current defaults for extra naturals,
then to guess whether this relates to extra naturals or not at all... Why?
I fail to see why this test (accidental.ly) would be less valuable if there
would be "\key
ter* the NEXT NOTE.
> I suppose this is an inherent issue but it would be great if it could be
> solved, it is really not logical and highly counter-intuitive...
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
lear top-to-system, top-to-markup, system-to-bottom etc.
But this is rather overengineering, probably. Don't know. Sorry for the noise.
> Because there is no system after the bottom?
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
n is really annoying and *absolutely not
> user-friendly* (not understandable from a user point of view).
>
> Sorry for this nonconstructive post.
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
as 1203:
http://code.google.com/p/lilypond/issues/detail?id=1203
Thank you.
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
2x 75$, 1x 10 €
> >
> >Marc
> >>Others: please send bounty offers to bug-lilypond.
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
f i am wrong, thanks!-)
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
n the scanned image. Sorry if this is my eyes' problem
again .)
>
> Thanks,
>
> Carl
--
Dmytro O. Redchuk
Bug Squad
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
h like "Added issue is always better then missed. We aware
of that fact that some issues may be "Invalid"; anyway in every case false
negatives are better then missed negatives. In a case Bug Squad member would
add invalid issue or mis-classify one, she (he) will be corrected in a nice
w
33 matches
Mail list logo
