WIP! Attempt at changing plugin loading structure

[uliska]

This doesn't work yet, but I want to submit it for review.

The idea is to create better modularity for the various exporter modules (see discussion at https://github.com/openlilylib/lilypond-export/pull/17#discussion_r228915990).

What I think is the right thing is how package.ily goes along with choosing the "backend"/target.

I also think that FileExport in api.scm does the right thing.

What does not work is making the export-lilypond function from within Humdrum.scm (so far this only touches the Humdrum file) available to api.scm. I really don't understand it because in my MWE it did work. (see https://github.com/openlilylib/lilypond-export/pull/17#discussion_r229066643)

[rshura]

I have to admit that I got no clue about modules, packages, and the best way to call things, either in scheme in general or in LP in particular. I'm very new to all of this, and I'm sure you guys will know how to expose this the best. Sorry, but I just don't have enough expertise and intuition to offer here :-)

[PaulMorris]

I don't have a good grasp on the OLL package mechanisms but I'll try to take a look (but likely not before this weekend).

[uliska]

@PaulMorris my problem is very little about how OLL's package mechanism, but mainly about how Scheme modules are handled in the different constellations between LilyPond code/files and Scheme code/files.

[PaulMorris]

Hi @uliska , I had a chance to take a look. I'm seeing this:

Starting lilypond 2.19.82 [export-example.ly]...
Processing `/lilypond-export/export-example.ly'
Parsing...
/lilypond-export/package.ily:35:2: error: GUILE signaled an error for the expression beginning here
#
 (use-modules (lilypond-export api))
no code for module (oll-core internal music-tools)
/lilypond-export/package.ily:54:5: In expression (FileExport (quasiquote #)):
/ly-to-musicxml/lilypond-export/package.ily:54:5: Unbound variable: FileExport
Exited with return code 1.

Is the problem the error "no code for module (oll-core internal music-tools)"? (Where this module is loaded at the top of lilypond-export/api.scm.) When I look in oll-core/internal/ I don't see a music-tools module there. I have checked out the current master branch of oll-core repo.

I tried checking out the previous commit in the lilypond-export repo b69b57937a101bd684fcd2ae9d32be507b2ffc2f (Move music-is? function...). I get a similar "no code for module (oll-core internal music-tools)" error:

Starting lilypond 2.19.82 [export-example.ly]...
Processing `/lilypond-export/export-example.ly'
Parsing...
/lilypond-export/package.ily:35:2: error: GUILE signaled an error for the expression beginning here
#
 (use-modules (lilypond-export api))
/lilypond-export/package.ily:45:2: error: GUILE signaled an error for the expression beginning here
#
 (let
/lilypond-export/export-example.ly:55:14: error: syntax error, unexpected \default
\exportMusic 
             \default hum \music
/lilypond-export/export-example.ly:57:18: error: GUILE signaled an error for the expression beginning here
opts.exporter = #
                 exportMusicXML
/lilypond-export/export-example.ly:62:5: error: unknown escaped string: `\FileExport'

    \FileExport #opts
/lilypond-export/export-example.ly:62:17: error: syntax error, unexpected SCM_TOKEN, expecting '.' or '=' or ','
    \FileExport 
                #opts
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
MIDI output to `export-example.midi'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-THBmpd'...
Converting to `export-example.pdf'...
Deleting `/tmp/lilypond-THBmpd'...
no code for module (oll-core internal music-tools)
Unbound variable: exportLilyPond
Unbound variable: exportMusicXML
fatal error: failed files: "/lilypond-export/export-example.ly"
Exited with return code 1.

I see the commit where music-is? is removed from lilypond-export, but not a commit where it was added to oll-core. Do I have the wrong oll-core branch or something? That's as far as i got.

[uliska]

Is the problem the error "no code for module (oll-core internal music-tools)"?

No, the problem comes later. Sorry for not being explicit enough, but the music-tools module is still on the unmerged pull request https://github.com/openlilylib/oll-core/pull/41 and its grob-tools branch.

BTW Scheme modules starting with oll-core are not in the internal directory of the repository but in scheme/oll-core, so music-tools resides in scheme/oll-core/internal/music-tools.scm

With that FileExport is found but then in https://github.com/openlilylib/lilypond-export/pull/19/files#diff-c7155ddda8f4cb08ec1cc013a8856450R59 , after "loading" the determined "plugin" module exporter is not found.

[jpvoigt]

Am 05.11.18 um 17:49 schrieb Urs Liska:

I think what I'm missing is somehow hidden in the |(let ((exporter (module-ref (resolve-module | line?

yes, the module is implicitly loaded there - it is like somewhere use-modules is called and then the desired object/function/whatever is imported. It is loaded once like any scheme-module. If we want to prevent the loading at all we can only rely on the filename of the module. I'd like to be able to retrieve a list of exporter objects to be able to get informations within some object-properties. And the exporter is just one lambda so I don't think having them loaded all - will there ever be more than 5 exporters? - will not lead to any RAM-problems. Though complex exporters might need some time to load? I doubt it significant, but if we want to load the exporter when it is actually used we can just use the module-ref thing in a loader-function and provide the available exporters in a symbol-list.

understandable?

[jpvoigt]

o yes, there is one thing: load-from-path loads the file into the current context. resolve-module loads the module into the guile-VM, retrieves the one object from the module, but leaves the current context untouched. If you retrieve the lilypond-export object from an exporter module you can store it in a list for later usage. If the object in an exporter is called lilypond-export it does not conflict with the other plugins because the lambda-object is not called by this name. Of course this resolve-module thing can happen within a loader-function to only load the needed exporters.

Am 05.11.18 um 18:01 schrieb Urs Liska:

@uliska commented on this pull request.

---

In api.scm https://github.com/openlilylib/lilypond-export/pull/19#discussion_r230831138:

@@ -41,12 +41,28 @@ (oll-core internal music-tools) (lilypond-export lily) (lilypond-export MusicXML)

• (lilypond-export Humdrum)
• ;(lilypond-export Humdrum)

If I'm not mistaken this approach doesn't help either with my problem. |resolve-module| allows loading a module by its name, but this seems to require the module being "used" too - so there's no /real/ advantage over using |load-from-path|.

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/openlilylib/lilypond-export/pull/19#discussion_r230831138, or mute the thread https://github.com/notifications/unsubscribe-auth/ADFWTjfpGyGQKraDTOECb71lCITOoKEcks5usG8AgaJpZM4X_92s.