Backward compatibility status

Backward compatibility status

[Ludovic Courtès]

Hello,

A number of Guile-using applications and libraries are tested against
the latest 1.9 release, using a recent stable release:

  http://hydra.nixos.org/jobset/nixpkgs/guile2test/with-status

As you can see, there’s a lot of red crosses, but you can help!  :-)

Here’s a summary of the reasons of these build failures:

| Name                                  | Cause                                           |
|---------------------------------------+-------------------------------------------------|
| autogen-5.9.8, beast-0.7.1 [1],       | GH                                              |
| drgeo-1.1.0, gnucash-2.2.9 [2],       | GH                                              |
| texmacs-1.0.7 [3] trackballs-1.1.4    | GH                                              |
| guile-cairo-1.4.0, guile-gnome-2.16.1 | depends on guile-lib                            |
| guile-lib-0.1.6                       | `define-macro-with-docs'                        |
| g-wrap-1.9.13                         | guile-lib, `scm_closure', `scm_add_method'      |
| lilypond-2.13.9                       | `scm_internal_hash_fold' & `scm_t_hash_fold_fn' |
| mailutils-2.1, dico-2.0 [4]           | `SCM_IM_*', `SCM_RESET_DEBUG_MODE', etc.        |
| mcron-1.0.4                           | invalid `configure' check                       |
| snd-9.4                               | `scm_i_procedure_arity'                         |

[1] https://bugzilla.gnome.org/show_bug.cgi?id=598490
[2] https://bugzilla.gnome.org/show_bug.cgi?id=598491
[3] http://article.gmane.org/gmane.editors.texmacs.devel/4006
[4] http://mail.gnu.org.ua/mailman/listarchive/bug-dico/2010-01/msg00000.html

Note how much GH is still used...

I think we should make the transition as smooth as we reasonably can.
To that end, you can take action in one of the following areas:

  1. See whether/how backward compatibility can be retained for each of
     these.

  2. Document how people are expected to transition away from the
     deprecated APIs, possibly provided Coccinelle semantic patches for
     C-level changes (see http://coccinelle.lip6.fr/).

  3. Contact application/library developers and help them transition
     to 2.0.

If you know of other apps/libraries worth testing, please let me know.

Thanks!

Ludo’.

Re: Backward compatibility status

[Patrick McCarty]

Hi,

2010/3/6 Ludovic Courtès <ludo@gnu.org>:
>
> A number of Guile-using applications and libraries are tested against
> the latest 1.9 release, using a recent stable release:
>
>  http://hydra.nixos.org/jobset/nixpkgs/guile2test/with-status
>
> As you can see, there’s a lot of red crosses, but you can help!  :-)

Thanks for posting this.

> Here’s a summary of the reasons of these build failures:
>
> | Name                                  | Cause                                           |
> |---------------------------------------+-------------------------------------------------|
> | lilypond-2.13.9                       | `scm_internal_hash_fold' & `scm_t_hash_fold_fn' |

Is this something that should be fixed in LilyPond?

For reference, I'm fairly certain this build failure was introduced
with Guile commit a07010bf1828704edd9a40cadb0eaf820b8f3638.

If I add the typedefs to the appropriate LilyPond header file and use
them, the problem goes away, but I don't know if there are unexpected
side effects of this.  I am unable to test any further, because there
are more build failures down the pipeline.  :-)

Thanks,
Patrick

Re: Backward compatibility status

[Ludovic Courtès]

Hi Patrick,

Patrick McCarty <pnorcks@gmail.com> writes:

> 2010/3/6 Ludovic Courtès <ludo@gnu.org>:

[...]

>> | Name                                  | Cause                                           |
>> |---------------------------------------+-------------------------------------------------|
>> | lilypond-2.13.9                       | `scm_internal_hash_fold' & `scm_t_hash_fold_fn' |
>
> Is this something that should be fixed in LilyPond?

I think so, yes (especially since ‘scm_internal_hash_fold’ was intended
to be sort-of internal.)

> For reference, I'm fairly certain this build failure was introduced
> with Guile commit a07010bf1828704edd9a40cadb0eaf820b8f3638.

Yes, that’s the one.

> If I add the typedefs to the appropriate LilyPond header file and use
> them, the problem goes away, but I don't know if there are unexpected
> side effects of this.

I think you want a fix that retains compatibility with 1.8.  How about
having a ‘configure’ test checking for this typedef?

> I am unable to test any further, because there are more build failures
> down the pipeline.  :-)

Heh.  Let us know what other Guile-related failures you stumble upon!

Thanks,
Ludo’.

Re: Backward compatibility status

[Ian Hulin]

Hi Ludo,

On 14/03/10 23:38, Ludovic � wrote:
> Hi Patrick,
>
> Patrick McCarty<pnorcks@gmail.com>  writes:
>
>> 2010/3/6 Ludovic Courtès<ludo@gnu.org>:
>
> [...]
>
>>> | Name                                  | Cause                                           |
>>> |---------------------------------------+-------------------------------------------------|
>>> | lilypond-2.13.9                       | `scm_internal_hash_fold'&  `scm_t_hash_fold_fn' |
>>
>> Is this something that should be fixed in LilyPond?
>
> I think so, yes (especially since ‘scm_internal_hash_fold’ was intended
> to be sort-of internal.)
>
>> For reference, I'm fairly certain this build failure was introduced
>> with Guile commit a07010bf1828704edd9a40cadb0eaf820b8f3638.
>
> Yes, that’s the one.
>
>> If I add the typedefs to the appropriate LilyPond header file and use
>> them, the problem goes away, but I don't know if there are unexpected
>> side effects of this.
>
> I think you want a fix that retains compatibility with 1.8.  How about
> having a ‘configure’ test checking for this typedef?
>
>> I am unable to test any further, because there are more build failures
>> down the pipeline.  :-)
>
> Heh.  Let us know what other Guile-related failures you stumble upon!
>

I patched the Lilypond header files and code calling them to get round 
the above problem, but then hit this one:

Code like this which dynamically declares procedures,and works fine in 
V1.8.7 but barfs with V1.9.9

;;; This is OK
(define-public PLATFORM
   (string->symbol
    (string-downcase
     (car (string-tokenize (utsname:sysname (uname)))))))

;;; This is OK


;;; This fails, but works in 1.8.7
(case PLATFORM
   ((windows)
    (define native-getcwd
      getcwd)

    (define (slashify x)
      (if (string-index x #\\)
	 x
	 (string-regexp-substitute
	  "//*" "/"
	  (string-regexp-substitute "\\\\" "/" x))))

    (define-public (ly-getcwd)
      (slashify (native-getcwd))))

   (else
    (define-public ly-getcwd
      getcwd)))

Re: Backward compatibility status

[Ludovic Courtès]

Hi Ian,

Ian Hulin <ian@hulin.org.uk> writes:

> I patched the Lilypond header files and code calling them to get round
> the above problem

Can you post a link to the patch?

> ;;; This fails, but works in 1.8.7
> (case PLATFORM
>   ((windows)
>    (define native-getcwd
>      getcwd)

Yes, that’s expected and it’s documented in ‘NEWS’, which also says that
we “may choose to revisit this situation before 2.0 in response to user
feedback”.  :-)

Anyway, something that will work with both 1.8 and 2.0 is this:

  (if (eq? PLATFORM 'windows)
      (begin
        (module-define! (current-module) 'native-getcwd getcwd)
        (module-define! ...)
        ...))

Hope this helps,
Ludo’.

Re: Backward compatibility status

[Patrick McCarty]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

Hi Ludo,

Sorry about the delayed response...

On 2010-03-15, Ludovic Courtès wrote:
> 
> Patrick McCarty <pnorcks@gmail.com> writes:
> 
> > 2010/3/6 Ludovic Courtès <ludo@gnu.org>:
> >> | Name              | Cause                                           |
> >> |-------------------+-------------------------------------------------|
> >> | lilypond-2.13.9   | `scm_internal_hash_fold' & `scm_t_hash_fold_fn' |
> >
> > Is this something that should be fixed in LilyPond?
> 
> I think so, yes (especially since ‘scm_internal_hash_fold’ was intended
> to be sort-of internal.)

Okay, thanks.  I didn't make that connection at first.  :-)

I think, eventually, LilyPond should migrate away from using these
"internal" functions, but that's not something I'm able to figure out
right now.

> > If I add the typedefs to the appropriate LilyPond header file and use
> > them, the problem goes away, but I don't know if there are unexpected
> > side effects of this.
> 
> I think you want a fix that retains compatibility with 1.8.  How about
> having a ‘configure’ test checking for this typedef?

Is the attached patch for LilyPond what you had in mind?

I'll apply it if it looks okay to you.  I've tested with both Guile
1.8 and 1.9, and it seems to work OK.

> > I am unable to test any further, because there are more build failures
> > down the pipeline.  :-)
> 
> Heh.  Let us know what other Guile-related failures you stumble upon!

I will.  Thanks, for your support.

Regards,
-Patrick

[-- Attachment #2: 0001-Add-checks-for-new-types-in-Guile-2.0.patch --]
[-- Type: text/plain, Size: 5140 bytes --]

From ce815a06b1cc91aa8dfd2a31a782e9a068a6e9d6 Mon Sep 17 00:00:00 2001
From: Patrick McCarty <pnorcks@gmail.com>
Date: Thu, 1 Apr 2010 17:39:52 -0700
Subject: [PATCH] Add checks for new types in Guile 2.0.

In order to preserve backward compatibility with Guile 1.8 and forward
compatibility with Guile 2.0 and later, add configure checks to
conditionally compile 2 new types used for (internal) hash-fold
procedures.

Eventually, LilyPond should migrate away from using functions that are
intended for internal use, but these checks will suffice for now.
---
 config.hh.in              |    3 +++
 configure.in              |    7 +++++++
 lily/general-scheme.cc    |    2 +-
 lily/include/ly-module.hh |    7 +++++--
 lily/ly-module.cc         |    9 ++++-----
 lily/module-scheme.cc     |    2 +-
 lily/scm-hash.cc          |    6 ++++--
 7 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/config.hh.in b/config.hh.in
index 7f43e21..3bcfa72 100644
--- a/config.hh.in
+++ b/config.hh.in
@@ -97,3 +97,6 @@
 
 /* define if you have pango FT2 binding */
 #define HAVE_PANGO_FT2 0
+
+/* define if Guile has types scm_t_hash_fold_fn and scm_t_hash_handle_fn */
+#define HAVE_GUILE_HASH_FUNC 0
diff --git a/configure.in b/configure.in
index f7547d1..cc3df1a 100644
--- a/configure.in
+++ b/configure.in
@@ -112,6 +112,13 @@ STEPMAKE_TEXMF(REQUIRED)
 STEPMAKE_TEXMF_DIRS
 STEPMAKE_GUILE_DEVEL(REQUIRED, 1.8.2)
 
+# check for 2 typedefs added in Guile 1.9
+save_CFLAGS="$CFLAGS"
+CFLAGS="$GUILE_CFLAGS $CFLAGS"
+AC_CHECK_TYPES([scm_t_hash_fold_fn, scm_t_hash_handle_fn],
+	       [AC_DEFINE(HAVE_GUILE_HASH_FUNC)], [],
+	       [#include <libguile.h>])
+CFLAGS="$save_CFLAGS"
 
 ## check rational bugfix.
 save_CPPFLAGS="$CPPFLAGS"
diff --git a/lily/general-scheme.cc b/lily/general-scheme.cc
index cd7e25d..d409ce0 100644
--- a/lily/general-scheme.cc
+++ b/lily/general-scheme.cc
@@ -462,7 +462,7 @@ LY_DEFINE (ly_hash_table_keys, "ly:hash-table-keys",
 	  1,0,0, (SCM tab),
 	  "Return a list of keys in @var{tab}.")
 {
-  return scm_internal_hash_fold ((Hash_closure_function) & accumulate_symbol,
+  return scm_internal_hash_fold ((scm_t_hash_fold_fn) &accumulate_symbol,
 				 NULL, SCM_EOL, tab);
 }
 
diff --git a/lily/include/ly-module.hh b/lily/include/ly-module.hh
index e9ab0b8..f301e59 100644
--- a/lily/include/ly-module.hh
+++ b/lily/include/ly-module.hh
@@ -33,8 +33,11 @@ SCM ly_clear_anonymous_modules ();
 void clear_anonymous_modules ();
 SCM ly_use_module (SCM mod, SCM used);
 
-/* Ugh signature of scm_internal_hash_fold () is inaccurate.  */
-typedef SCM (*Hash_closure_function) (GUILE_ELLIPSIS);
+/* For backward compatability with Guile 1.8 */
+#if !HAVE_GUILE_HASH_FUNC
+typedef SCM (*scm_t_hash_fold_fn) (GUILE_ELLIPSIS);
+typedef SCM (*scm_t_hash_handle_fn) (GUILE_ELLIPSIS);
+#endif
 
 #define MODULE_GC_KLUDGE
 
diff --git a/lily/ly-module.cc b/lily/ly-module.cc
index 07fdc53..b5880a0 100644
--- a/lily/ly-module.cc
+++ b/lily/ly-module.cc
@@ -126,7 +126,8 @@ LY_DEFINE (ly_module_2_alist, "ly:module->alist",
   SCM_VALIDATE_MODULE (1, mod);
   SCM obarr = SCM_MODULE_OBARRAY (mod);
 
-  return scm_internal_hash_fold ((Hash_closure_function) & entry_to_alist, NULL, SCM_EOL, obarr);
+  return scm_internal_hash_fold ((scm_t_hash_fold_fn) &entry_to_alist,
+				 NULL, SCM_EOL, obarr);
 }
 
 void
@@ -188,10 +189,8 @@ make_stand_in_procs_weak ()
   SCM old_tab = scm_stand_in_procs;
   SCM new_tab = scm_make_weak_key_hash_table (scm_from_int (257));
 
-  new_tab = scm_internal_hash_fold ((Hash_closure_function) & redefine_keyval,
-				    NULL,
-				    new_tab,
-				    old_tab);
+  new_tab = scm_internal_hash_fold ((scm_t_hash_fold_fn) &redefine_keyval,
+				    NULL, new_tab, old_tab);
 
   scm_stand_in_procs = new_tab;
 }
diff --git a/lily/module-scheme.cc b/lily/module-scheme.cc
index 192fcf4..b58bf15 100644
--- a/lily/module-scheme.cc
+++ b/lily/module-scheme.cc
@@ -47,7 +47,7 @@ LY_DEFINE (ly_module_copy, "ly:module-copy",
 {
 #define FUNC_NAME __FUNCTION__
   SCM_VALIDATE_MODULE (1, src);
-  scm_internal_hash_fold ((Hash_closure_function) & module_define_closure_func,
+  scm_internal_hash_fold ((scm_t_hash_fold_fn) &module_define_closure_func,
 			  (void *) dest,
 			  SCM_EOL, SCM_MODULE_OBARRAY (src));
   return SCM_UNSPECIFIED;
diff --git a/lily/scm-hash.cc b/lily/scm-hash.cc
index bb73d52..058f3be 100644
--- a/lily/scm-hash.cc
+++ b/lily/scm-hash.cc
@@ -39,7 +39,8 @@ copy_handle (void *closure, SCM handle)
 static void
 copy_scm_hashes (SCM dest, SCM src)
 {
-  scm_internal_hash_for_each_handle (  (SCM (*)(GUILE_ELLIPSIS)) &copy_handle, dest, src);
+  scm_internal_hash_for_each_handle ((scm_t_hash_handle_fn) &copy_handle,
+				     dest, src);
 }
 
 Scheme_hash_table::Scheme_hash_table ()
@@ -142,7 +143,8 @@ collect_handles (void * /* closure */,
 SCM
 Scheme_hash_table::to_alist () const
 {
-  return scm_internal_hash_fold ((SCM (*)(GUILE_ELLIPSIS)) &collect_handles, NULL, SCM_EOL, hash_tab_);
+  return scm_internal_hash_fold ((scm_t_hash_fold_fn) &collect_handles,
+				 NULL, SCM_EOL, hash_tab_);
 }
 
 IMPLEMENT_SMOBS (Scheme_hash_table);
-- 
1.7.0.3

Re: Backward compatibility status

[Ludovic Courtès]

Hi Patrick,

Patrick McCarty <pnorcks@gmail.com> writes:

> On 2010-03-15, Ludovic Courtès wrote:

[...]

>> I think you want a fix that retains compatibility with 1.8.  How about
>> having a ‘configure’ test checking for this typedef?
>
> Is the attached patch for LilyPond what you had in mind?

Yes.

Thanks,
Ludo’.