Thomas Morley <[email protected]> writes: > 2016-11-12 15:50 GMT+01:00 Thomas Morley <[email protected]>: >> 2016-11-12 15:42 GMT+01:00 David Kastrup <[email protected]>: >>> Thomas Morley <[email protected]> writes: >>> >>>>> The main problem I remember was a coding problem. It did not like >>>>> working with UTF-8 characters. >>>> >>>> >>>> Do you mean the encoding-problem is responsible for the failed >>>> markup-cyclic-reference.ly? >>> >>> Very unlikely. >>> >>>> Or for the stuck while doc-building? >>> >>> Possibly but also unlikely. I remembered straightforward errors when >>> using files with UTF-8 characters in them (and there were a number). >>> And the file for demonstrating &oe; and similar HTML characters turned >>> out wrong. No error I think, just wrong. >>> >>> -- >>> David Kastrup >> >> Just seen Antonio continued his work: >> https://ao2.it/tmp/lilypond-guile2/ >> >> Here what he did: >> https://ao2.it/tmp/lilypond-guile2/NOTES_2016-11-10.txt >> >> He claims to get a successful >> make doc >> >> Will look into it more thoroughly later the day. >> >> Cheers, >> Harm > > Well, I tried to do the same as Antonio, but it didn't work out for me > and I don't have a clue why. > > So I tried to go back several steps: > i.e. check out remotes/origin/dev/guilev21, derive a local branch from > it, rebase it against current master and then do make -j5 > > It fails with the error: > /home/hermann/lilypond-git/lily/source-file.cc: In member function > 'void Source_file::init_port()': > /home/hermann/lilypond-git/lily/source-file.cc:163:71: error: > 'ly_lily_module_constant' was not declared in this scope > scm_dynwind_fluid (ly_lily_module_constant > ("%default-port-encoding"), SCM_BOOL_F); > > The relevant patch in remotes/origin/dev/guilev21 is: > > commit 9eaf40c79f064b0d303df6d47edcdf124d84dec9 > Author: David Kastrup <[email protected]> > Date: Sun Sep 21 18:40:06 2014 +0200 > > Source_file::init_port: Keep GUILEv2 from redecoding string input > > diff --git a/lily/guile-init.cc b/lily/guile-init.cc > index 4270aa0..c1bbf7e 100644 > --- a/lily/guile-init.cc > +++ b/lily/guile-init.cc > @@ -56,6 +56,14 @@ ly_init_ly_module () > for (vsize i = scm_init_funcs_->size (); i--;) > (scm_init_funcs_->at (i)) (); > > +#if GUILEV2 > + // We need binary ports for any of our standard input operations, > + // and the precompiled API calls for those crash inexplicably if we > + // have not explicitly loaded the module anyway. > + // Cf <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20209>. > + (void) scm_c_resolve_module ("ice-9 binary-ports"); > +#endif > + > if (is_loglevel (LOG_DEBUG)) > { > debug_output ("[", true); > diff --git a/lily/source-file.cc b/lily/source-file.cc > index 14fdf2b..eaa5ee0 100644 > --- a/lily/source-file.cc > +++ b/lily/source-file.cc > @@ -151,8 +151,22 @@ Source_file::init_port () > // This is somewhat icky: the string will in general be in utf8, but > // we do our own utf8 encoding and verification in the parser, so we > // use the no-conversion equivalent of latin1 > +#if GUILEV2 > + SCM str = scm_c_make_bytevector (length () - 1); > + memcpy (SCM_BYTEVECTOR_CONTENTS (str), c_str (), length () - 1); > + // Setting %default-port-encoding to binary before calling > + // open-bytevector-input-port appears quite unnecessary regarding > + // the documented semantics, but at least GUILE 2.0.11 is not > + // particularly interested in sticking to its documentation. > + // <URL:http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20200> > + scm_dynwind_begin ((scm_t_dynwind_flags)0); > + scm_dynwind_fluid (ly_lily_module_constant > ("%default-port-encoding"), SCM_BOOL_F); > + str_port_ = scm_open_bytevector_input_port (str, SCM_UNDEFINED); > + scm_dynwind_end (); > +#else > SCM str = scm_from_latin1_string (c_str ()); > str_port_ = scm_mkstrport (SCM_INUM0, str, SCM_OPN | SCM_RDNG, > __FUNCTION__); > +#endif > scm_set_port_filename_x (str_port_, ly_string2scm (name_)); > } > > > > I don't understand whats wrong. > > Hints?
I saw a patch for this in his notes or branches or whatever. ly_lily_module_constant no longer exists; this is done using the lily/lily-imports.cc and lily/include/lily-imports.hh files now. If you cannot figure this out, I can try to upgrade/rebase the old branch, assuming that its operation is indeed necessary. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
