Re: guile-2.0 and debian

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2016-11-12 15:50 GMT+01:00 Thomas Morley <address@hidden>:
>> 2016-11-12 15:42 GMT+01:00 David Kastrup <address@hidden>:
>>> Thomas Morley <address@hidden> 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 <address@hidden>
> 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