Re: Embed LilyPond source files inside generated PDF (issue 225040043 by address@hidden)

[dak]

https://codereview.appspot.com/225040043/diff/40001/lily/sources.cc
File lily/sources.cc (right):

https://codereview.appspot.com/225040043/diff/40001/lily/sources.cc#newcode78
lily/sources.cc:78: source_file_list = scm_cons (ly_string2scm
(file_string), source_file_list);
On 2015/04/10 08:10:57, Valentin Villenave wrote:
> On 2015/04/09 13:37:42, dak wrote:
> > any reason you don't rely on the per-parser array source_files_ for
your
> > list of source files?

> Assuming you’re referring to the sourcefiles_ vector, that was my plan
> initially. How can I access it outside its (Sources
constructor/destructor)
> scope so that I can convert it into a Scheme list?

You cannot access any value after its destructor has been called or
equivalently its dynamic scope ended.  The destructor of some Smob data
structure is called by the Scheme garbage collector.

Sources is not a Scheme controlled structure, but its containing lexer
is, and its contained Source_file elements are.  Somewhat awkwardly,
they are not protected through the usual mark procedures but by
retaining them in protected state until the destructor of Sources is
called.

At any rate: while a lexer is Scheme-accessible, the elements of its
sourcefiles_ structure should be accessible as well.

In this particular case, it would appear that
Includable_lexer::file_name_strings_ already contains properly expanded
file names after the file name search has succeeded, so that would seem
to be the smarter thing to reference.

> > if I do lilypond
> > -fembed-source-files a.ly b.ly
> > the PDF for b.ly will include the source(s) for a.ly.

> Hm, indeed. (And with more than two .ly files, Guile GC complains.) I
hoped the
> SCM_INIT_FUNC mechanism would prevent it, but it obviously gets
initialized only
> once.

> > I might add that you forget to protect it from garbage collection,
likely
> inducing crashes

> I couldn’t find an example of a protected global variable (protected:
is always
> used inside a class, and scm_gc_mark in engravers or iterators). But
I’ll be
> happy to learn more.

protected: has nothing to do with protection from garbage collection: it
is a C++ visibility construct.

A global variable that is automatically protected from garbage
collection can be created as type Protected_scm (after including the
relevant header file).  Funnily, this type is barely used in the
LilyPond code base even though available since 1998.

https://codereview.appspot.com/225040043/diff/40001/lily/sources.cc#newcode126
lily/sources.cc:126: }
There is a lot wrong with this loop.  You destructively change
source_file_list here.  Which is bad.  But any elements you remove from
the start of lst are _not_ removed from source_file_list.  Since you
throw away lst after the loop ends, they will still be present in
source_file_list and returned by this function.  I think you would be
better advised to just return the list of all source files (presumably
when given a parser as argument) and do any pruning at the Scheme level
using `filter'.  Less opportunity for messing up.

https://codereview.appspot.com/225040043/