Re: Eliminates the Hara_kiri_engraver. (issue 7061062)

[dak]

Comment #7 from Keith has not been addressed as far as I can see, but I
have to admit that I don't understand a thing from it, so I can't
estimate whether it is mistaken or indicates a real usage problem.

Other than that, it looks like a welcome simplification.


https://codereview.appspot.com/7061062/diff/9001/lily/axis-group-engraver.cc
File lily/axis-group-engraver.cc (right):

https://codereview.appspot.com/7061062/diff/9001/lily/axis-group-engraver.cc#newcode122
lily/axis-group-engraver.cc:122: if (staffline_ &&
to_boolean(staffline_->get_property("remove-empty")))
If "sneaky callback" is a real concern, it would be feasible to just
store a copy of remove-empty in the engraver right after staffline_ has
been created.

However, I don't really think that a sneaky callback could cause any
awful effects: it would just likely remove a group too many or too few
because of missing or spurious bookkeeping.

https://codereview.appspot.com/7061062/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Question re pushing to staging

[Ian Hulin]

Hi James,

On 19/01/13 20:50, James wrote:
> Ian.
> 
> On 19 January 2013 17:26, Ian Hulin  > wrote:
> 
> Hi all,
> 
> I've just tried my first push to staging so a load of commenting I
> added to main.cc for the Guile 2 conversion work didn't get lost. The
> patch ran make check and make doc OK locally.
> 
> I followed the instructions in CG 3.4.11 and marked Tracker 1686
> Fixed. �When should I see a thumbs up/thumbs down post on -auto?
> 
> Did I get the process right?
> 
> 
> 
> Looking at the tracker, not really. :)
> 

D'oh!! Sorry to all for getting this wrong.

It had already been through a Rietveld review, and the feedback I got
was "OK, tweak this bit, but how about pushing to staging so all the
comments are preserved".
> As far as this ought to have gone (and someone will correct me if I am
> wrong) is that a dev uses (for instance) git-cl to upload code to
> Rietveld, this sets the tracker to Patch-New and then when someone (i.e.

I modified the label to Fixed instead of Patch-New. Sorry.

Do I need to do anything so we get a proper audit trail?

Cheers,

Ian

> me) runs Patchy - the suite of scripts to test patches - I will put it
> through a full make, make test, make doc and check the reg tests and
> then if all that si ok, the scripts set the patch to Patch-review, then
> the other devs check rietveld and assuming nothing is bad, the issue
> goes to Patch-countdown and the after a few days (countdown being a 'hey
> devs, this is going to get permission to be pushed so make sure you have
> looked' flag) it will be marked as pushed on the tracker (this is all
> handled by one of the non-devs) and then you push it to staging.
> 
> So you sort of skipped the formalities, but at least it was pushed to
> staging.
> 
> Then my server runs the merge scripts every two hours - checks to see if
> staging is updated, then does a merge, a full make, make test and make
> doc again (just to be sure) and then pushes to master.
> 
> 
> James
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: scheme debugging error

[Marco Heins]

>
> Hi Ian,
>
> thank you for your very detailed answer! I have very high respect for you
> and the other developers who spent lots of time & brain on improving
> lilypond and hope I didn't keep you away from more importent issues with my
> newbe questions. "Temperamental" is a nice word for the debuggers behaviour
> :-)
>
> I hope you recoverd well from your illness!
>
> I tought I might be a good idea to look at the complex process of lilypond
> from a top-down perspective first, but due to the current "under
> construction"-state of the guile-debugger maybe I better start diving into
> c++-source with gdb?!
>
> @David
>
> Thanks for your answer, setting the guile-path variable didn't fix it
> unter windows, under ubuntu different errors appear (readline is not
> provided in this guile installation)
>

 I also have a question concerning graphviz: One is adviced not to install
lilypond after compiling under Lilydev, but in order to run graphviz I have
to, havn't I? Or can I set some paths to make lilypond work without
installing?

> Cheers
> Marco
>
>
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: scheme debugging error

[David Kastrup]

Marco Heins  writes:

> Hi Ian,
> 
> thank you for your very detailed answer! I have very high respect
> for you and the other developers who spent lots of time & brain on
> improving lilypond and hope I didn't keep you away from more
> importent issues with my newbe questions. "Temperamental" is a
> nice word for the debuggers behaviour :-)
> 
> I hope you recoverd well from your illness!
> 
> I tought I might be a good idea to look at the complex process of
> lilypond from a top-down perspective first, but due to the current
> "under construction"-state of the guile-debugger maybe I better
> start diving into c++-source with gdb?!
> 
> @David
> 
> Thanks for your answer, setting the guile-path variable didn't fix
> it unter windows, under ubuntu different errors appear (readline
> is not provided in this guile installation)
> I also have a question concerning graphviz: One is adviced not to
> install lilypond after compiling under Lilydev, but in order to run
> graphviz I have to, havn't I? Or can I set some paths to make lilypond
> work without installing?

The uninstalled LilyPond executable (sitting in out/bin) will be able to
find its corresponding data in the source tree.  Just call it.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Eliminates the Hara_kiri_engraver. (issue 7061062)

[mtsolo]

"sneaky callback" is not a real concern...it's a pedantic concern.
If we're following the model to a T, grob properties should not be read
in engravers, just set.  The idea is that the engravers are creating the
grobs and fixing them up with properties if need be.  I prefer
duplicating a context and grob property rather than just having the grob
property, but people seem against this.  It is a trivial fix if people
become for it.

I think Keith's comment is fixed in this patch set (although I must
admit that I don't completely follow it either...this is a new corner of
the code for me).

https://codereview.appspot.com/7061062/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: CG: explicitly detail the correct values for git cl config (issue 7096052)

[graham]

On 2013/01/14 14:11:18, Julien Rioux wrote:

At this point, the git-cl used by the project has been sufficiently

geared

towards lilypond development that I somewhat doubt anybody is using it

for work

outside of lilypond. It might not make sense at all for "our" git-cl

to keep

asking these superfluous questions; should they be remove entirely?


Sure, go ahead and remove them.  You still have push access to git-cl.


https://codereview.appspot.com/7096052/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Merging

[Francisco Vila]

Hello,
I plan to perform the following in a few hours or days.

merge master on translation
test make doc
push to translation
merge translation on staging
test make doc
push to staging

If nobody opposes.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel