Re: Backend and non-backend (was Re: Stencil bounding box)

David Feuer wrote:
> On 4/27/06, Han-Wen Nienhuys <hanwen <at> lilypond.org> wrote:
> 
>> Frankly, I'm a bit mystified why you're spending so much time on
>> building the ultimate postscript backend.  The backend is not a
>> performance bottleneck. If you think the current PS code is inefficient,
>> then you should have a look at the rest of LilyPond.
> 
> Could you suggest something else to work on that would be reasonably
> easy to understand?

there's one idea that I've been toying in my head with for a bit.

One of the major problems is that we don't have a reliable way to test 
LilyPond automatically: the output is a PDF file, and changes in 
formatting may subtly alter PDF files between versions, which throws off 
a diff or cmp with a reference file.

However, I think it should be possible to generate a "signature" of the 
output from within the backend, and use that to detect changes in 
formatting. The idea is that the output is characterized by the set of 
grobs used for the output.

Each grob is characterized by :

  * its name
  * its bounding box
  * its stencil output expression

The output expression contains a lot of floating point numbers, which 

Re: Spacing patch

Joe Neeman wrote:

>> I'm also not certain if these are normal.
> Given that this is where lilypond exits with an error, I'd hope not ;). It 
> turns out that this is caused by guile 1.6. The compatibility hack
> (if (not (defined? 'inf?))
>     (define-public (inf? x) #f))
> was letting infs through. I guess it's time to upgrade...

You could also export a ly:inf? from lilypond.

--

-- 

Han-Wen Nienhuys - hanwen <at> lilypond.org - http://www.xs4all.nl/~hanwen

LilyPond Software Design
  -- Code for Music Notation
http://www.lilypond-design.com

Re: Spacing patch

On Mon, 1 May 2006 09:35, Han-Wen Nienhuys wrote:
> Joe Neeman wrote:
> >> I'm also not certain if these are normal.
> >
> > Given that this is where lilypond exits with an error, I'd hope not ;).
> > It turns out that this is caused by guile 1.6. The compatibility hack (if
> > (not (defined? 'inf?))
> >     (define-public (inf? x) #f))
> > was letting infs through. I guess it's time to upgrade...
>
> You could also export a ly:inf? from lilypond.

I was having trouble[1] getting 1.8 to work on amd64, so I've actually already 
done a patch. It allows me to finish "make web", but maybe exporting a C++ 
function would be more reliable?

[1] http://article.gmane.org/gmane.lisp.guile.devel/5805

2006-05-01  Joe Neeman  <joeneeman <at> gmail.com>

	* scm/lily-library.scm: Fix guile 1.6 compatibility in inf? and nan?

_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Spacing patch

Joe Neeman wrote:
>>> was letting infs through. I guess it's time to upgrade...
>> You could also export a ly:inf? from lilypond.
> 
> I was having trouble[1] getting 1.8 to work on amd64, so I've actually already 
> done a patch. It allows me to finish "make web", but maybe exporting a C++ 
> function would be more reliable?
> 
> [1] http://article.gmane.org/gmane.lisp.guile.devel/5805
> 
> 2006-05-01  Joe Neeman  <joeneeman <at> gmail.com>
> 
> 	* scm/lily-library.scm: Fix guile 1.6 compatibility in inf? and nan?
> 
> 
> ------------------------------------------------------------------------
> 
> Index: scm/lily-library.scm
> ===================================================================
> RCS file: /sources/lilypond/lilypond/scm/lily-library.scm,v
> retrieving revision 1.62
> diff -u -r1.62 lily-library.scm
> --- scm/lily-library.scm	31 Mar 2006 00:23:26 -0000	1.62
> +++ scm/lily-library.scm	30 Apr 2006 23:47:37 -0000
>  <at>  <at>  -320,10 +320,12  <at>  <at> 
>  ;; numbers
>  
>  (if (not (defined? 'nan?)) ;; guile 1.6 compat
> -    (define-public (nan? x) #f))
> +    (define-public (nan? x) (not (or (< 0.0 x)

Re: Spacing patch

On Mon, 1 May 2006 10:04, Han-Wen Nienhuys wrote:
> looks good. Please apply.
Done (my first CVS commit! very exciting :))

> If you have checked that the regtest document 
> looks ok, please apply the spacing patch too.

I have a couple regressions that may be caused by my spacing patch (or maybe 
by some of my other changes). But I'll hold off on commiting until I have 
figured out where they come from.

Re: Backend and non-backend (was Re: Stencil bounding box)

On 4/30/06, Han-Wen Nienhuys <hanwen <at> lilypond.org> wrote:
> David Feuer wrote:
> > On 4/27/06, Han-Wen Nienhuys <hanwen <at> lilypond.org> wrote:
> >
>
> One of the major problems is that we don't have a reliable way to test
> LilyPond automatically: the output is a PDF file, and changes in
> formatting may subtly alter PDF files between versions, which throws off
> a diff or cmp with a reference file.

This sounds interesting.  I'm not sure I like the specific approach
you've taken, but yes, I'd be interested in tackling this problem. 
Would it be possible to refactor the backends first?  I'd be really
happy if that were complete.  In fact, one of the ways I'm thinking
about rewriting the PostScript backend would likely make this kind of
analysis somewhat easier.

David

Re: Backend and non-backend (was Re: Stencil bounding box)

David Feuer schreef:

>> One of the major problems is that we don't have a reliable way to test
>> LilyPond automatically: the output is a PDF file, and changes in
>> formatting may subtly alter PDF files between versions, which throws off
>> a diff or cmp with a reference file.
> 
> This sounds interesting.  I'm not sure I like the specific approach
> you've taken, but yes, I'd be interested in tackling this problem. Would 
> it be possible to refactor the backends first?  I'd be really
> happy if that were complete.  

I don't see who would benefit from a refactoring of the backend, so IMO 
it's a waste of time.  By contrast, having a continuous distance measure 
between different outputs would speed development up tremendously, 
because we will be able to spot and repair bugs as soon as they crop up.

You're free to submit patches to the backend, though.

--

-- 

Han-Wen Nienhuys - hanwen <at> lilypond.org - http://www.xs4all.nl/~hanwen

LilyPond Software Design
  -- Code for Music Notation
http://www.lilypond-design.com

Re: Backend and non-backend (was Re: Stencil bounding box)

On 5/1/06, Han-Wen Nienhuys <hanwen <at> lilypond.org> wrote:

> I don't see who would benefit from a refactoring of the backend, so IMO
> it's a waste of time.  By contrast, having a continuous distance measure
> between different outputs would speed development up tremendously,
> because we will be able to spot and repair bugs as soon as they crop up.
>
> You're free to submit patches to the backend, though.

Refactoring:  anyone who wants to write a new backend or edit an
existing one, and anyone who wants compact output files.

Distance measure:  I don't yet understand what kinds of changes you
want to be considered significant and what kinds you want to be
considered insignificant.

David Feuer

Re: Backend and non-backend (was Re: Stencil bounding box)

David Feuer schreef:
> On 5/1/06, Han-Wen Nienhuys <hanwen <at> lilypond.org> wrote:
> 
>> I don't see who would benefit from a refactoring of the backend, so IMO
>> it's a waste of time.  By contrast, having a continuous distance measure
>> between different outputs would speed development up tremendously,
>> because we will be able to spot and repair bugs as soon as they crop up.
>>
>> You're free to submit patches to the backend, though.
> 
> Refactoring:  anyone who wants to write a new backend or edit an
> existing one, and anyone who wants compact output files.

Given that we haven't had anyone writing or modifying the backend in the 
past 5 years, I doubt that there is much need for this.

> Distance measure:  I don't yet understand what kinds of changes you
> want to be considered significant and what kinds you want to be
> considered insignificant.

it should take geometry and appearance into account, ie. where the 
symbols end up on the page, and how large they are. What I would really 
want is to have a similarity measure for the image produced by two PDF 
files, but that's a rather hard problem, and it will be easier if we 
take advantage of the fact that we can access the backend.

I think the main problem is to make the measure invariant under changes 
that do not influence the end result.  Eg. due to internal restructuring 
grobs might be output in a different order between versions or runs. 
That should not affect the distance measure.

Re: Backend and non-backend (was Re: Stencil bounding box)

On 5/1/06, Han-Wen Nienhuys <hanwen <at> lilypond.org> wrote:

> Given that we haven't had anyone writing or modifying the backend in the
> past 5 years, I doubt that there is much need for this.

I've been working on it ...

> it should take geometry and appearance into account, ie. where the
> symbols end up on the page, and how large they are. What I would really
> want is to have a similarity measure for the image produced by two PDF
> files, but that's a rather hard problem, and it will be easier if we
> take advantage of the fact that we can access the backend.

Well, if you care about where things are on the page, one option would
be just to compare PNGs.  Otherwise:  the new backend design I'm
considering would flatten stencils.  This should make it really easy
to pull out a list of elements, sorted in any convenient fashion.

David