lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile-2.0 and debian


From: Thomas Morley
Subject: Re: guile-2.0 and debian
Date: Sat, 12 Nov 2016 23:01:23 +0100

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?


Cheers,
  Harm



reply via email to

[Prev in Thread] Current Thread [Next in Thread]