> "Han-Wen" == Han-Wen Nienhuys writes:
Han-Wen> On Thu, Jun 17, 2010 at 9:55 AM, Pap Lôrinc
Han-Wen> wrote:
Han-Wen> Regarding 'long long', flower/include/flower-proto.hh says
Han-Wen> typedef long long I64;
Han-Wen> but this is wrong, as it is not conditional on the
Han-Wen> architect
I'm trying to do regression test checking, but it doesn't seem to be working
right.
I did
make test-baseline
Then I switched to my new branch and did
make && make check
I found some differences, so I patched the code, then did
make test-redo
make check
After this, I got a comparison output t
On 2010/06/17 20:04:53, Neil Puttock wrote:
On 2010/06/17 19:49:26, Patrick McCarty wrote:
> Adding the following code fixes the memory leak Neil refers to,
though there
> might be a better way.
>
> (if (ly:get-option 'svg-woff)
> (module-define! (ly:outputter-module outputter) 'paper #f
Just a few more comments...
http://codereview.appspot.com/1428042/diff/34001/35014
File scm/output-svg.scm (right):
http://codereview.appspot.com/1428042/diff/34001/35014#newcode25
scm/output-svg.scm:25: ;;; set by framework-gnome.scm
;;; set by framework-svg.scm
http://codereview.appspot.com/
On 2010/06/17 19:49:26, Patrick McCarty wrote:
Adding the following code fixes the memory leak Neil refers to, though
there
might be a better way.
(if (ly:get-option 'svg-woff)
(module-define! (ly:outputter-module outputter) 'paper #f))
Ah, that's cute. :)
I was searching throught t
Can you give me a higher resolution scan of a push and pull symbol, so I can
see what a good one looks like?
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On 6/17/10 1:37 PM, "David Kastrup" wrote:
>
>
> Here is a scan from typical uses of push and pull symbols (the very
> first symbol is "pull" in every piece). The symbols usually appear
> _before_ the fingering, at somewhat constant height independent from the
> actual notes.
>
> They are use
http://codereview.appspot.com/1428042/diff/34001/35011
File scm/framework-svg.scm (right):
http://codereview.appspot.com/1428042/diff/34001/35011#newcode138
scm/framework-svg.scm:138: (dump (svg-end))
Adding the following code fixes the memory leak Neil refers to, though
there might be a better
Here is a scan from typical uses of push and pull symbols (the very
first symbol is "pull" in every piece). The symbols usually appear
_before_ the fingering, at somewhat constant height independent from the
actual notes.
They are used somewhat in analog with upbow/downbow symbols for bowed
stri
Hi Joe,
From what I can tell, LGTM. `make check' is okay, and I can't reproduce
the erroneous offset anymore.
http://codereview.appspot.com/1694041/show
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lily
2010/6/17 Valentin Villenave :
> Absolutely. That's why I've always said that we should have something
> like a "bounty thermometer" (such as the one they use for Blender's
> open movies IIRC, or http://haikuware.com/bounties/ as well).
Agree.
At this time there is nothing on the official LilyPon
On Thu, Jun 17, 2010 at 9:17 AM, Carl Sorensen wrote:
> On 6/17/10 9:48 AM, "Neil Puttock" wrote:
>
>> On 17 June 2010 16:42, Carl Sorensen wrote:
>>
>>> The problem I have is that after the assertion fails, the temp directory is
>>> removed:
>>>
assert stat == 0
AssertionError
>>>
Graham Percival writes:
> On Thu, Jun 17, 2010 at 09:08:35AM -0600, Carl Sorensen wrote:
>>
>> On 6/17/10 8:59 AM, "David Kastrup" wrote:
>> > Moving existing Lilypond mode stuff into Emacs upstream will require
>> > copyright assignments to the FSF. A fast hunch whether authors of the
>> > cu
On Thu, Jun 17, 2010 at 11:56:02AM +0200, Reinhold Kainhofer wrote:
> Am Donnerstag, 17. Juni 2010, 05:56:06 schrieb Carl Sorensen:
> > On 6/16/10 9:41 PM, "Han-Wen Nienhuys" wrote:
> > > [+lilypond-devel, can this be automatic for codereviews?]
> >
> > Yes -- it's part of the git-cl configurati
On Thu, Jun 17, 2010 at 09:08:35AM -0600, Carl Sorensen wrote:
>
> On 6/17/10 8:59 AM, "David Kastrup" wrote:
> > Moving existing Lilypond mode stuff into Emacs upstream will require
> > copyright assignments to the FSF. A fast hunch whether authors of the
> > current Lilypond mode can be determ
On 6/17/10 9:48 AM, "Neil Puttock" wrote:
> On 17 June 2010 16:42, Carl Sorensen wrote:
>
>> The problem I have is that after the assertion fails, the temp directory is
>> removed:
>>
>>> assert stat == 0
>>> AssertionError
>>> rm -rf /var/folders/Rv/RvqP2cCoEOawyy1FGSxWZU+++TI/-Tmp-/tmphO
On Thu, Jun 17, 2010 at 3:56 PM, wrote:
>> Did you run the regression test?
>
> - I just did (make check?), it fails (I guess, I'm not sure what to
> look for).
This is absolutely critical for any large-scale code change.
>> If we are doing a fixup of this, we should try to do all files at th
On 17 June 2010 16:42, Carl Sorensen wrote:
> The problem I have is that after the assertion fails, the temp directory is
> removed:
>
>> assert stat == 0
>> AssertionError
>> rm -rf /var/folders/Rv/RvqP2cCoEOawyy1FGSxWZU+++TI/-Tmp-/tmphOUJQb
>
>
> So my crop1 file is now gone, and I can't do
On 6/17/10 9:16 AM, "Han-Wen Nienhuys" wrote:
> On Thu, Jun 17, 2010 at 11:38 AM, Carl Sorensen wrote:
>> I'm trying to run the regression tests. Make test-baseline runs just fine.
>
>
>> invoking convert -depth 8 -crop 637x108+0+0
>> /Users/Carl/lilypond/out/test-results/input/regression/
Carl Sorensen writes:
> On 6/17/10 8:59 AM, "David Kastrup" wrote:
>
>>
>>
>> Hi,
>>
>> I have a question about developing Emacs input and major modes for
>> Lilypond. What would be the right way to go forward for me?
>>
>> I want to make use of current Emacs features (like semantic parsing
On Thu, Jun 17, 2010 at 11:38 AM, Carl Sorensen wrote:
> I'm trying to run the regression tests. Make test-baseline runs just fine.
> invoking convert -depth 8 -crop 637x108+0+0
> /Users/Carl/lilypond/out/test-results/input/regression/out-test/tuplet-prope
> rties.png
> /var/folders/Rv/RvqP2cCo
On 6/17/10 8:59 AM, "David Kastrup" wrote:
>
>
> Hi,
>
> I have a question about developing Emacs input and major modes for
> Lilypond. What would be the right way to go forward for me?
>
> I want to make use of current Emacs features (like semantic parsing and
> similar). I also want to c
Hi,
I have a question about developing Emacs input and major modes for
Lilypond. What would be the right way to go forward for me?
I want to make use of current Emacs features (like semantic parsing and
similar). I also want to create input methods for inputting on the
keyboard in chromatic bu
I ask that you submit the changes in a separated way: it's easier to
review, and if it does break something, it's easier to identify and
revert the incriminating commit.
- Okay, I will resubmit some non-controversial parts of it in the near
future.
but just removing the check is not the right
I'm trying to run the regression tests. Make test-baseline runs just fine.
When I do
make check
it goes along for a while, and seemingly identifies the files that are
different, then fails:
reading input/regression/out-test//tree.gittxt
no source for <__main__.GitFileCompareLink instance at 0
Han-Wen Nienhuys writes:
> On Thu, Jun 17, 2010 at 9:55 AM, Pap Lôrinc wrote:
>
>> (and I also think that too many preprocessor macros are used ... but
>> I'm no expert, please don't take my opinion as an insult). I
>
> What is 'too many' ? Which macros could we do without?
Arguably creating de
On Thu, Jun 17, 2010 at 2:35 PM, Han-Wen Nienhuys wrote:
> it's not that I want things untouched, it's that
>
> * I don't want someone else to come along and change formatting details again.
Absolutely; we've had this problem too many times in the documentation.
> * If we are doing a fixup of th
On Thu, Jun 17, 2010 at 9:55 AM, Pap Lôrinc wrote:
>> * in case you are doing cosmetic changes, can you double check that your
>> standards are part of the style guide - I recall it is not that strict in
>> many areas, and in many cases there is no real reason to choose one over the
>> other. * I
On Tue, Jun 15, 2010 at 5:34 PM, Graham Percival
wrote:
> I believe the highest bounty so far was 250 euro, back in the days
> when Han-Wen was working full-time and Trevor Baca was requesting many
> new features.
FTR -- The highest bounty I ever paid was 500 euros, in 2007.
On Tue, Jun 15, 2010
On Thu, Jun 17, 2010 at 9:55 AM, Pap Lôrinc wrote:
> - it *is* cosmetics, it's just that the unmarked casting to int made it
> seemingly possible to be < 0, which it cannot be, since fm->name_to_index
> (key) returns an unsigned positive value anyway
#include
main() {
unsigned x = -1;
int
On Thu, Jun 17, 2010 at 6:47 AM, Jan Nieuwenhuizen
wrote:
> Op donderdag 17-06-2010 om 00:41 uur [tijdzone -0300], schreef Han-Wen
> Nienhuys:
>
>> > * Why are all the casts there?
>
> casts are mostly bad and often indication that something is wrong.
>
>> It is probably an easier fix to change v
http://codereview.appspot.com/1724041/show>
> * can you split this up by type
of change? ie. one commit doing cosmetics of comments, one changing inline
functions, one for casts etc. This makes reviewing easier: a commit touching
only comments can be approved with
much less scrutiny than one w
Am Donnerstag, 17. Juni 2010, 05:56:06 schrieb Carl Sorensen:
> On 6/16/10 9:41 PM, "Han-Wen Nienhuys" wrote:
> > [+lilypond-devel, can this be automatic for codereviews?]
>
> Yes -- it's part of the git-cl configuration. Run
One of the problems is that some devels (like me) are subscribed wit
Op donderdag 17-06-2010 om 00:41 uur [tijdzone -0300], schreef Han-Wen
Nienhuys:
> > * Why are all the casts there?
casts are mostly bad and often indication that something is wrong.
> It is probably an easier fix to change vsize to be an int again.
This may be easiest fix and probably wrong.
> * Why are many lines wrapped at 60-80 (while some at 100)?
> * This makes reading the code hard, console mode wrapping
> * seems deprecated to me (especially on my 24'' monitor). I
> * think that 95-110 chars/line are better in most cases then
> * wrapping @ 80.
I
35 matches
Mail list logo
