PHP to GUILE

PHP to GUILE

[Vorfeed Canal]

After latest PHP fiasco (when "maintenance release" PHP 5.0.5 broke
most PHP programs) I decided that "enough is enough - I need to change
language for future projects".

I've checked with few alternatives and found that I like SXML better
then other packages (Perl, Python, etc). Thus GUILE - it's "official"
implementation of Scheme for GNU system, right.

Unfortunatelly while support for XML in scheme (and guile) is
excellent this is not the only thing needed for web-programming. I
found some problems with GUILE core and lack of usefull modules
(perhaps two problems are related?).

Problems with GUILE core:

1. All C extension files can only be put in /usr/lib - there are no
sane way to change libtool's searchpath and there are no sane default.
Very annoying.

2. No way to use standard (for modern languages like C++, PHP or Java)
scheme with throw/catch and EXCEPTIONS HIERARCHY.

Problems with GUILE extesions:

1. Good MySQL binding: both SimpleSQL and Guile-DBI do not give you
access to even basic stuff like mysql_insert_id. Guile-PG looks
promising but is not compatible with Guile 1.7.x (and earlier versions
do not support SMP)...

2. No GD/ImageMagick bindings (or are there ones?).

3. GuileFCGI is not compatible with GUILE 1.6.x or GUILE 1.7.x. There
are mod_lisp (with GUILE module) but it does not support responses
without known length (and it's not always feasible to create answer in
"one go"). What are advantages of mod_lisp over mod_fastcgi ?

While problems with GUILE extensions are not critical (I'll be happy
if someone will show me good MySQL or ImageMagick bindings but I can
write them myself if there will be no other choice) problems with
GUILE core are other story.

About first problem: default extensions load path ONLY includes three
directories: "/lib", "/usr/lib" and "." (in this order). You can
change it from scheme with (setenv "LTDL_LIBRARY_PATH"
"/usr/local/blah") but there are no standard place to put extensions
while normal script languages have one or two (like Perl's site_perl
vs vendor_perl). It can de fixed with simple patch (see below), so
real question is "why the hell it was not done five years ago?" ...

About second problem. GNU Kawa (if we are talking about GNU GUILE it
makes sense to borrow from GNU Kawa, right?) has the following
solution to this problem:

http://per.bothner.com/tmp/kawa/Exceptions.html

primitive-throw exception

    Throws the exception, which must be an instance of a sub-class of
<java.lang.Throwable>.

Syntax: try-finally body handler

    Evaluate body, and return its result. However, before it returns,
evaluate handler. Even if body returns abnormally (by throwing an
exception), handler is evaluated.

    (This is implemented just like Java's try-finally.)

Syntax: try-catch body handler ...

    Evaluate body, in the context of the given handler specifications.
Each handler has the form:

    var type exp ...

    If an exception is thrown in body, the first handler is selected
such that the thrown exception is an instance of the handler's type.
If no handler is selected, the exception is propagated through the
dynamic execution context until a matching handler is found. (If no
matching handler is found, then an error message is printed, and the
computation terminated.)

    Once a handler is selected, the var is bound to the thrown
exception, and the exp in the handler are executed. The result of the
try-catch is the result of body if no exception is thrown, or the
value of the last exp in the selected handler if an exception is
thrown.

    (This is implemented just like Java's try-catch.)

Kawa does not support GOOPS-style overloading so may be it's better to
just remake throw and catch as "primitive with generic", declare
"try-finally" and "try-catch" as aliases to "catch", "primitive-throw"
as alias to "throw" and then make default exceptions catchable via
GOOPS exceptions classes ? This way "normal" catch/throw semantics
will not be affected but when GOOPS is loaded you'll get
sane^H^H^H^Hmodern exceptions handling...

This is part where I do not know how change to core should look in the
end (one thing is clear: exceptions without hierarchy are not very
usefull), but with search path it's obvious: it should be something
like this:

diff -uNr guile-1.7.2.orig/guile-config/guile.m4
guile-1.7.2/guile-config/guile.m4
--- guile-1.7.2.orig/guile-config/guile.m4      2003-04-05
23:01:16.000000000 +0400
+++ guile-1.7.2/guile-config/guile.m4   2005-09-18 23:15:30.000000000 +0400
@@ -110,6 +110,24 @@
   AC_SUBST(GUILE_SITE)
  ])

+# GUILE_SITELIB_DIR -- find path to Guile "site" lirbraries directory
+#
+# Usage: GUILE_SITELIB_DIR
+#
+# This looks for Guile's "site" libraries directory, usually something
+# like PREFIX/lib/guile/site, and sets var @var{GUILE_SITELIB} to the path.
+# Note that the var name is different from the macro name.
+#
+# The variable is marked for substitution, as by @code{AC_SUBST}.
+#
+AC_DEFUN([GUILE_SITELIB_DIR],
+ [AC_REQUIRE([GUILE_PROGS])dnl
+  AC_MSG_CHECKING(for Guile site libraries directory)
+  GUILE_SITE=`[$GUILE_CONFIG] info pkglibdir`/site
+  AC_MSG_RESULT($GUILE_SITEDIR)
+  AC_SUBST(GUILE_SITEDIR)
+ ])
+
 # GUILE_CHECK -- evaluate Guile Scheme code and capture the return value
 #
 # Usage: GUILE_CHECK_RETVAL(var,check)
diff -uNr guile-1.7.2.orig/libguile/dynl.c guile-1.7.2/libguile/dynl.c
--- guile-1.7.2.orig/libguile/dynl.c    2005-03-04 01:12:31.000000000 +0300
+++ guile-1.7.2/libguile/dynl.c 2005-09-18 23:51:56.000000000 +0400
@@ -52,9 +52,37 @@
 #include "libguile/lang.h"
 #include "libguile/validate.h"
 #include "libguile/dynwind.h"
+#include "libguile/srfi-13.h"
+#include "libguile/load.h"
+#include "libguile/libpath.h"

 #include <ltdl.h>

+/* List of names of directories we search for files to load.  */
+static SCM *scm_loc_load_path;
+
+/* Initialize the global variable %load-libpath, given the value of the
+   SCM_SITELIB_DIR and SCM_LIB_DIR preprocessor symbols and the
+   GUILE_LOAD_LIBPATH environment variable.  */
+static void
+scm_init_load_libpath ()
+{
+  char *env;
+  SCM path = SCM_EOL;
+
+#ifdef SCM_LIB_DIR
+  path = scm_list_3 (scm_from_locale_string (SCM_SITELIB_DIR),
+                     scm_from_locale_string (SCM_LIB_DIR),
+                     scm_from_locale_string (SCM_PKGLIB_DIR));
+#endif /* SCM_LIB_DIR */
+
+  env = getenv ("GUILE_LOAD_LIBPATH");
+  if (env)
+    path = scm_parse_path (scm_from_locale_string (env), path);
+
+  *scm_loc_load_path = path;
+}
+
 /*
   From the libtool manual: "Note that libltdl is not threadsafe,
   i.e. a multithreaded application has to use a mutex for libltdl.".
@@ -68,8 +95,16 @@
 static void *
 sysdep_dynl_link (const char *fname, const char *subr)
 {
-  lt_dlhandle handle;
-  handle = lt_dlopenext (fname);
+  lt_dlhandle handle = NULL;
+  SCM scm_search_path = scm_string_join (*scm_loc_load_path,
+                                        scm_from_locale_string (":"),
+                                        SCM_UNDEFINED/*scm_sym_infix*/);
+  char * search_path = scm_to_locale_string (scm_search_path);
+  scm_frame_free (search_path);
+  if (!lt_dlsetsearchpath (search_path))
+    {
+      handle = lt_dlopenext (fname);
+    }
   if (NULL == handle)
     {
       SCM fn;
@@ -314,6 +349,8 @@
   scm_tc16_dynamic_obj = scm_make_smob_type ("dynamic-object", 0);
   scm_set_smob_mark (scm_tc16_dynamic_obj, dynl_obj_mark);
   scm_set_smob_print (scm_tc16_dynamic_obj, dynl_obj_print);
+  scm_loc_load_path = SCM_VARIABLE_LOC (scm_c_define
("%load-libpath", SCM_EOL));
+  scm_init_load_libpath ();
   sysdep_dynl_init ();
 #include "libguile/dynl.x"
 }
diff -uNr guile-1.7.2.orig/libguile/Makefile.am guile-1.7.2/libguile/Makefile.am
--- guile-1.7.2.orig/libguile/Makefile.am       2005-03-08
02:03:23.000000000 +0300
+++ guile-1.7.2/libguile/Makefile.am    2005-09-18 23:23:44.000000000 +0400
@@ -234,6 +234,9 @@
        @echo '#define SCM_PKGDATA_DIR "$(pkgdatadir)"' >> libpath.tmp
        @echo '#define SCM_LIBRARY_DIR
"$(pkgdatadir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
        @echo '#define SCM_SITE_DIR "$(pkgdatadir)/site"' >> libpath.tmp
+       @echo '#define SCM_PKGLIB_DIR "$(pkglibdir)"' >> libpath.tmp
+       @echo '#define SCM_LIB_DIR
"$(pkglibdir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
+       @echo '#define SCM_SITELIB_DIR "$(pkglibdir)/site"' >> libpath.tmp
        @echo '#define SCM_BUILD_INFO { \' >> libpath.tmp
        @echo ' { "srcdir", "'"`cd @srcdir@; pwd`"'" }, \' >> libpath.tmp
        @echo ' { "top_srcdir",    "@top_srcdir_absolute@" }, \' >> libpath.tmp
diff -uNr guile-1.7.2.orig/libguile/Makefile.in guile-1.7.2/libguile/Makefile.in
--- guile-1.7.2.orig/libguile/Makefile.in       2005-03-08
03:42:07.000000000 +0300
+++ guile-1.7.2/libguile/Makefile.in    2005-09-18 23:23:50.000000000 +0400
@@ -1898,6 +1898,9 @@
        @echo '#define SCM_PKGDATA_DIR "$(pkgdatadir)"' >> libpath.tmp
        @echo '#define SCM_LIBRARY_DIR
"$(pkgdatadir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
        @echo '#define SCM_SITE_DIR "$(pkgdatadir)/site"' >> libpath.tmp
+       @echo '#define SCM_PKGLIB_DIR "$(pkglibdir)"' >> libpath.tmp
+       @echo '#define SCM_LIB_DIR
"$(pkglibdir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
+       @echo '#define SCM_SITELIB_DIR "$(pkglibdir)/site"' >> libpath.tmp
        @echo '#define SCM_BUILD_INFO { \' >> libpath.tmp
        @echo ' { "srcdir", "'"`cd @srcdir@; pwd`"'" }, \' >> libpath.tmp
        @echo ' { "top_srcdir",    "@top_srcdir_absolute@" }, \' >> libpath.tmp


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Kevin Ryde]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> 1. All C extension files can only be put in /usr/lib - there are no
> sane way to change libtool's searchpath and there are no sane default.
> Very annoying.

With a full path to `load-extension' you can put a module anywhere.
If your code is a package in its own right then this is a good thing,
so you can be certain to get the right file (ie. whatever crazy
directory the user might have given).


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Zeeshan Ali]

Hi,

On 9/26/05, Kevin Ryde <user42@zip.com.au> wrote:
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
> >
> > 1. All C extension files can only be put in /usr/lib - there are no
> > sane way to change libtool's searchpath and there are no sane default.
> > Very annoying.
>
> With a full path to `load-extension' you can put a module anywhere.
> If your code is a package in its own right then this is a good thing,
> so you can be certain to get the right file (ie. whatever crazy
> directory the user might have given).

  Yeah! and you can have a look at the source code of xchat-guile to
see how exactly thats done:
http://piipiip.net/~zeenix/xchat-guile-0.2.tar.gz

--
Regards,

Zeeshan Ali


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/26/05, Kevin Ryde <user42@zip.com.au> wrote:
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> With a full path to `load-extension' you can put a module anywhere.

But you can not give control to user then !

> If your code is a package in its own right then this is a good thing,
> so you can be certain to get the right file (ie. whatever crazy
> directory the user might have given).

If you are writing stand-alone package then it can be good thing, yes.
But if you are writing extension module for GUILE... USER or may be
APPLICATION WRITER must be in control, not GUILE!

If you'll run Guile-GNOME's configure without specifying --prefix
you'll see this:

-- cut --
Guile-GNOME requires you to explicitly enter in a prefix when
configuring. This is because the default prefix, /usr/local, is not in
the default guile load path. What you probably want to do is to run

  ./configure --prefix=/usr

so that guile can find the guile-gnome modules when they are installed.

If you choose to install to a prefix that is not in guile's load path,
you will need to modify GUILE_LOAD_PATH and LD_LIBRARY_PATH every time
you run guile. (Which is a pain.)
-- cut --

This means I'm not the only one who feel like this hardcoded path is
not a good solution.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/26/05, Zeeshan Ali <zeenix@gmail.com> wrote:

> > With a full path to `load-extension' you can put a module anywhere.
> > If your code is a package in its own right then this is a good thing,
> > so you can be certain to get the right file (ie. whatever crazy
> > directory the user might have given).
>
>   Yeah! and you can have a look at the source code of xchat-guile to
> see how exactly thats done:
> http://piipiip.net/~zeenix/xchat-guile-0.2.tar.gz

I took a look. Conclusion: it's a mess.

Why? Easy: guile.so is installed in /usr/lib/xchat/plugins while
plugin-system.scm in installed iin /usr/share/guile/site/xchat-guile.
Ok, if it's in /usr/share/guile/site/xchat-guile then it's guile
extension, right ? Sorry, but no:
guile> (use-modules (xchat-guile plugin-system))

Backtrace:
In unknown file:
   ?: 14* (if (or # #) (try-load-module name))
   ?: 15  [try-load-module (xchat-guile plugin-system)]
   ?: 16  (or (begin (try-module-linked name)) (try-module-autoload name) ...)
   ?: 17* [try-module-autoload (xchat-guile plugin-system)]
   ?: 18  (let* (# # # #) (resolve-module dir-hint-module-name #f) (and # #))
    ...
   ?: 19  (letrec ((load-file #)) (dynamic-wind (lambda () #) (lambda
() #) ...) ...)
   ?: 20* [dynamic-wind #<procedure #f ()> #<procedure #f ()>
#<procedure #f ()>]
   ?: 21* [#<procedure #f ()>]
   ?: 22* (let* ((file #)) (cond (# => #) (# => #)))
   ?: 23  [#<procedure #f #>
"/usr/share/guile/site/xchat-guile/plugin-system.scm"]
   ?: 24  [load-file #<primitive-procedure primitive-load> ...]
   ?: 25* [save-module-excursion #<procedure #f ()>]
   ?: 26  (let (# #) (dynamic-wind # thunk #))
   ?: 27  [dynamic-wind #<procedure #f ()> #<procedure #f ()>
#<procedure #f ()>]
   ?: 28* [#<procedure #f ()>]
   ?: 29* [primitive-load "/usr/share/guile/site/xchat-guile/plugin-system.scm"]
In /usr/share/guile/site/xchat-guile/plugin-system.scm:
   6: 30* (use-modules (xchat-guile main))
   6: 31  (eval-case (# # *unspecified*) (else #))
   6: 32  (begin (process-use-modules (list (list #))) *unspecified*)
In unknown file:
   ?: 33* [process-use-modules (((xchat-guile main)))]

<unnamed port>: In procedure process-use-modules in expression
(process-use-modules (list #)):
<unnamed port>: no code for module (xchat-guile main)
ABORT: (misc-error)

And in this case it's easy to move plugin-system.scm to
/usr/lib/xchat/plugins (where it belongs) since guile DOES have
adjustable %load-path . GUILE does NOT have something similar for
native libraries. That's the problem.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Thien-Thi Nguyen]

   From: Vorfeed Canal <vorfeed.canal@gmail.com>
   Date: Mon, 26 Sep 2005 11:43:59 +0400

   This means I'm not the only one who feel like this hardcoded path is
   not a good solution.

you may be able to get guile 1.4.x[1] to do what you want.  all the
compiled modules (shared object libraries following a certain loading
convention) of Guile-SDL and Guile-PG, for example, are not installed
under /usr/local/lib.

those packages use "module catalogs", which is another (IMHO superior)
resolution mechanism, but anyway guile 1.4.x provides `%%ltdl' to expose
low level (prefix-path-munging) mechanisms from libltdl, should you
prefer that kind of control.

(hmmm, i just checked to see if there are online docs for `%%ltdl', but
there aren't (yet), so i will write some shortly and post a link in
another message -- in the meantime, you can look at the source file
guile-1.4.1.106/libguile/lt.c for ideas.)

thi


[1] http://www.glug.org/people/ttn/software/guile/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Exceptions

[Ludovic Courtès]

Hi,

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> 2. No way to use standard (for modern languages like C++, PHP or Java)
> scheme with throw/catch and EXCEPTIONS HIERARCHY.

[...]

> About second problem. GNU Kawa (if we are talking about GNU GUILE it
> makes sense to borrow from GNU Kawa, right?) has the following
> solution to this problem:
>
> http://per.bothner.com/tmp/kawa/Exceptions.html
>
> primitive-throw exception
>
>     Throws the exception, which must be an instance of a sub-class of
> <java.lang.Throwable>.

Well, this is the object-oriented approach to exceptions.  That doesn't
mean you can't obtain a similar result using Guile's current exception
mechanism.

In particular, the KEY arg passed to `throw' and `catch' can be thought
of as the ``class'' of the exception being thrown/caught.  One of the
additional arguments can be thought of as a subtype of the exception
(see, for instance, `system-error' and `system-error-errno').
Admittedly, this may sometimes be more verbose than the use of a class
hierarchy mechanism.

Fortunately, `guile-library' contains an implementation of SRFI-35's
hierarchical error conditions, and both `guile-library' and Guile (1.7)
implement SRFI-34's exception handling routines.  Only SRFI-36 (I/O
error conditions) is missing.

So I guess there's no valid reason not to use Guile.  :-)

Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/26/05, Thien-Thi Nguyen <ttn@glug.org> wrote:
>    From: Vorfeed Canal <vorfeed.canal@gmail.com>
>    Date: Mon, 26 Sep 2005 11:43:59 +0400
>
>    This means I'm not the only one who feel like this hardcoded path is
>    not a good solution.
>
> you may be able to get guile 1.4.x[1] to do what you want.  all the
> compiled modules (shared object libraries following a certain loading
> convention) of Guile-SDL and Guile-PG, for example, are not installed
> under /usr/local/lib.
>

And they are incompatible with pthreads and are not using GOOPS at
all. Thnx, but no thnx.

> those packages use "module catalogs", which is another (IMHO superior)
> resolution mechanism, but anyway guile 1.4.x provides `%%ltdl' to expose
> low level (prefix-path-munging) mechanisms from libltdl, should you
> prefer that kind of control.
>

Hmm... And why "module catalogs" are superior ? I see one reason for
their existence, but may be there are ones. For example I view this
feature: "the actual placement of the file in the filesystem is
decoupled from its module name" as DISadvantage... I mean: we need
hierarchy of modules, we have perfect system to organize objects in
hierarchy called "filesystem" why we'll ever want to replace it
without very compelling reasons?

> (hmmm, i just checked to see if there are online docs for `%%ltdl', but
> there aren't (yet), so i will write some shortly and post a link in
> another message -- in the meantime, you can look at the source file
> guile-1.4.1.106/libguile/lt.c for ideas.)

The biggest problem with this mechanism is that it's unsupported by
official version. I can as well just go back to PHP and revert
unneeded changes. After all I was able to revert this:
http://cvs.php.net/diff.php/ZendEngine2/zend_execute.c?r1=1.652.2.38&r2=1.652.2.39&ty=u
and now my old PHP scripts are Ok. I want STABLE SUPPORTED language,
not something I'll be destined to keep in working state myself.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Zeeshan Ali]

Hello,

> >   Yeah! and you can have a look at the source code of xchat-guile to
> > see how exactly thats done:
> > http://piipiip.net/~zeenix/xchat-guile-0.2.tar.gz
>
> I took a look. Conclusion: it's a mess.

     Your conclusion is based on your ignorance.

> Why? Easy: guile.so is installed in /usr/lib/xchat/plugins while
> plugin-system.scm in installed iin /usr/share/guile/site/xchat-guile.
> Ok, if it's in /usr/share/guile/site/xchat-guile then it's guile
> extension, right ? Sorry, but no:
> guile> (use-modules (xchat-guile plugin-system))
>
> Backtrace:

    Please at least read the log yourself first, it's not (xchat-guile
plugin-system) that guile is unable to find but the xchat's main
module that is defined inside the xchat plugin, writen in C.

> And in this case it's easy to move plugin-system.scm to
> /usr/lib/xchat/plugins (where it belongs) since guile DOES have
> adjustable %load-path . GUILE does NOT have something similar for
> native libraries. That's the problem.
>

    plugin-system is NOT an xchat plugin but a guile module that the
xchat-guile plugin uses. Since it's a guile module, IMHO it doesn't
belong in directory for xchat plugins.

    Two more points:

1. I forgot that xchat-guile doesn't load the plugins as modules
anymore, so i am really sorry for directing you to a wrong turn.

2. Since guile doesn't allow you to 'unplug' modules on the run, I had
to do some trick to make it work, which makes it a bit complicated,
but it's not a mess. :)

--
Regards,

Zeeshan Ali


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/26/05, Zeeshan Ali <zeenix@gmail.com> wrote:
> >
> > I took a look. Conclusion: it's a mess.
>
>  Your conclusion is based on your ignorance.
>
Possible. Care to enlighten men ?

> Please at least read the log yourself first, it's not (xchat-guile
> plugin-system) that guile is unable to find but the xchat's main
> module that is defined inside the xchat plugin, writen in C.
>
Ok. And then why your plugin-system never loaded this main module instead ?

> > And in this case it's easy to move plugin-system.scm to
> > /usr/lib/xchat/plugins (where it belongs) since guile DOES have
> > adjustable %load-path . GUILE does NOT have something similar for
> > native libraries. That's the problem.
>
> plugin-system is NOT an xchat plugin but a guile module that the
> xchat-guile plugin uses.

Ok. No problem. If this "is NOT an xchat plugin" but simple guile
module then it usable without xchat, right ? This means (use-modules
(xchat-guile plugin-system)) works, right ? Oops. It does not.
Conclusion: it's NOT guile module but part of xchat module. It's
written in scheme but it does not make it guile module. Just like the
fact that your guile.so is written in C does not make it C library.

> Since it's a guile module, IMHO it doesn't belong in directory for xchat plugins.
>
But it's NOT guile module - my simple test proved it. That's the problem.

Let's take a look on lilypond:
/usr/share/lilypond/2.6.3/ps - postscript helper routines
/usr/share/lilypond/2.6.3/scm - guile modules
/usr/share/lilypond/2.6.3/tex - tex macroses

Sane ? Sane: it does not matter if it's in scheme and interpereted by
guile interpereter or in tex and interpreted by etex - if it's
unusable outside of lilypond it does not belong to /usr/share/guile
and/or /usr/share/texmf.

Now xchat and xchat-guile.
/usr/lib/xchat/plugins/perl.so - ok, xchat<->perl glue
/usr/lib/xchat/plugins/xas.pl - xchat plugins written in perl
/usr/lib/xchat/plugins/guile.so - ok, xchat<->guile glue
/usr/share/guile/site/xchat-guile/plugin-system.scm - WTF ?

Why the hell part of xchat<->guile glue code does in default guile
%load-path ? Is it usable outside of xchat ? If yes - then how exactly
it's usable ? If not - then why it's not in /usr/lib/xchat/plugins or
/usr/lib/xchat/guile or something like that ?

> 2. Since guile doesn't allow you to 'unplug' modules on the run, I had
> to do some trick to make it work, which makes it a bit complicated,
> but it's not a mess. :)

I was not reffering to plugin-system.scm contents but to it's place in
filesystem. It's a mess. May be it's unavoidable mess, I do not know
(I fail to see why it's unavoidable but who knows) - but it's a mess
nonetheless.Simple question: can I install two different versions of
xchar with two different versions of xchat-guile glue code ? Answer:
no - we'll get clash in
/usr/share/guile/site/xchat-guile/plugin-system.scm. And why that
happened ? Since this file does not belong to /usr/share/guile/site
directory in first place but was put there anyway.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exceptions

[Vorfeed Canal]

On 9/26/05, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
>
> Fortunately, `guile-library' contains an implementation of SRFI-35's
> hierarchical error conditions, and both `guile-library' and Guile (1.7)
> implement SRFI-34's exception handling routines.  Only SRFI-36 (I/O
> error conditions) is missing.
>
I can live with this for now - not very convenient, but not a disaster
either. I'll need to play around with these SRFI's and their
implementations, but at least it looks promising.

> So I guess there's no valid reason not to use Guile.  :-)
>
Not yet. At least with object hierarchy of exceptions answer now looks
clear: there are different but equally sane solution OUTSIDE of GUILE
core. Ok. But what about GUILE extensions written in C ? Lack of sane
place to put C glue libraries bothers me. Not since this is such a big
issue - it's minor issue.And THAT is reason it's bothering me: why
project with over 8 years history STILL has such minor basic issues
unresolved ? Are there are developers who can support GUILE or is it
semi-abandoned project like HURD ? What goes on ? May be this stuff is
handled by outside extension as well ? If so - then why ? And what is
name of said extension ? Why it's unused by existiong extensions like
guile-gnome-platform ? This sort of things...


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Zeeshan Ali]

Hello again,

> >  Your conclusion is based on your ignorance.
> >
> Possible. Care to enlighten men ?

   I already did but you seem to be too eager to prove your point.

> Ok. And then why your plugin-system never loaded this main module instead ?

    Because i'ts the opposite, the maim module actually loads the
plugin-system module. Please read the source, which is only one C
file.

> Ok. No problem. If this "is NOT an xchat plugin" but simple guile
> module then it usable without xchat, right ?

    I didn't say that it's not related to xchat or the xchat-plugin
that needs this module.

> This means (use-modules
> (xchat-guile plugin-system)) works, right ? Oops. It does not.
> Conclusion: it's NOT guile module but part of xchat module.

   You seem to be very eager to derive conclusions. Your problem seems
to be that you are making it an either/or situation (i-e either it's a
'pure' and 'independent' guile module or it's a pure and independent
xchat plugin), which is not the case here.

> It's
> written in scheme but it does not make it guile module. Just like the
> fact that your guile.so is written in C does not make it C library.

   In my last email i explicitly declared the main-module to be writen
in C, so i am obviously not assuming anything like that.

> > Since it's a guile module, IMHO it doesn't belong in directory for xchat plugins.
> >
> But it's NOT guile module - my simple test proved it. That's the problem.

    And i proved your test to be based on ignorance, perhaps you are
better off coding in PHP. :) Anyway, thats my last email, if you dont
get it this time either, stop calling my hard-work 'a mess'.

--
Regards,

Zeeshan Ali


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Neil Jerram]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> Unfortunatelly while support for XML in scheme (and guile) is
> excellent this is not the only thing needed for web-programming. I
> found some problems with GUILE core and lack of usefull modules
> (perhaps two problems are related?).

If you mean just that Guile isn't finished yet, then yes.

> Kawa does not support GOOPS-style overloading so may be it's better to
> just remake throw and catch as "primitive with generic", declare
> "try-finally" and "try-catch" as aliases to "catch", "primitive-throw"
> as alias to "throw" and then make default exceptions catchable via
> GOOPS exceptions classes ? This way "normal" catch/throw semantics
> will not be affected but when GOOPS is loaded you'll get
> sane^H^H^H^Hmodern exceptions handling...

Yes, I've been thinking about this approach for some time.  It's just
a matter of time available, and I personally don't have much of that
right now.

> This is part where I do not know how change to core should look in the
> end (one thing is clear: exceptions without hierarchy are not very
> usefull), but with search path it's obvious: it should be something
> like this:

Commenting on the following to make sure I understand ...

> diff -uNr guile-1.7.2.orig/guile-config/guile.m4
> guile-1.7.2/guile-config/guile.m4
> --- guile-1.7.2.orig/guile-config/guile.m4      2003-04-05
> 23:01:16.000000000 +0400
> +++ guile-1.7.2/guile-config/guile.m4   2005-09-18 23:15:30.000000000 +0400
> @@ -110,6 +110,24 @@
>    AC_SUBST(GUILE_SITE)
>   ])
>
> +# GUILE_SITELIB_DIR -- find path to Guile "site" lirbraries directory
> +#
> +# Usage: GUILE_SITELIB_DIR
> +#
> +# This looks for Guile's "site" libraries directory, usually something
> +# like PREFIX/lib/guile/site, and sets var @var{GUILE_SITELIB} to the path.
> +# Note that the var name is different from the macro name.
> +#
> +# The variable is marked for substitution, as by @code{AC_SUBST}.
> +#
> +AC_DEFUN([GUILE_SITELIB_DIR],
> + [AC_REQUIRE([GUILE_PROGS])dnl
> +  AC_MSG_CHECKING(for Guile site libraries directory)
> +  GUILE_SITE=`[$GUILE_CONFIG] info pkglibdir`/site
> +  AC_MSG_RESULT($GUILE_SITEDIR)
> +  AC_SUBST(GUILE_SITEDIR)
> + ])
> +

Presumably (apart from the GUILE_SITE/GUILE_SITEDIR typo) this is for
Guile packages, so they can install .sos to GUILE_SITEDIR.

>  # GUILE_CHECK -- evaluate Guile Scheme code and capture the return value
>  #
>  # Usage: GUILE_CHECK_RETVAL(var,check)
> diff -uNr guile-1.7.2.orig/libguile/dynl.c guile-1.7.2/libguile/dynl.c
> --- guile-1.7.2.orig/libguile/dynl.c    2005-03-04 01:12:31.000000000 +0300
> +++ guile-1.7.2/libguile/dynl.c 2005-09-18 23:51:56.000000000 +0400
> @@ -52,9 +52,37 @@
>  #include "libguile/lang.h"
>  #include "libguile/validate.h"
>  #include "libguile/dynwind.h"
> +#include "libguile/srfi-13.h"
> +#include "libguile/load.h"
> +#include "libguile/libpath.h"
>
>  #include <ltdl.h>
>
> +/* List of names of directories we search for files to load.  */
> +static SCM *scm_loc_load_path;

scm_loc_load_libpath would be better.

> +
> +/* Initialize the global variable %load-libpath, given the value of the
> +   SCM_SITELIB_DIR and SCM_LIB_DIR preprocessor symbols and the
> +   GUILE_LOAD_LIBPATH environment variable.  */
> +static void
> +scm_init_load_libpath ()
> +{
> +  char *env;
> +  SCM path = SCM_EOL;
> +
> +#ifdef SCM_LIB_DIR
> +  path = scm_list_3 (scm_from_locale_string (SCM_SITELIB_DIR),
> +                     scm_from_locale_string (SCM_LIB_DIR),
> +                     scm_from_locale_string (SCM_PKGLIB_DIR));
> +#endif /* SCM_LIB_DIR */
> +
> +  env = getenv ("GUILE_LOAD_LIBPATH");
> +  if (env)
> +    path = scm_parse_path (scm_from_locale_string (env), path);
> +
> +  *scm_loc_load_path = path;
> +}
> +
>  /*
>    From the libtool manual: "Note that libltdl is not threadsafe,
>    i.e. a multithreaded application has to use a mutex for libltdl.".
> @@ -68,8 +95,16 @@
>  static void *
>  sysdep_dynl_link (const char *fname, const char *subr)
>  {
> -  lt_dlhandle handle;
> -  handle = lt_dlopenext (fname);
> +  lt_dlhandle handle = NULL;
> +  SCM scm_search_path = scm_string_join (*scm_loc_load_path,
> +                                        scm_from_locale_string (":"),
> +                                        SCM_UNDEFINED/*scm_sym_infix*/);
> +  char * search_path = scm_to_locale_string (scm_search_path);
> +  scm_frame_free (search_path);
> +  if (!lt_dlsetsearchpath (search_path))
> +    {
> +      handle = lt_dlopenext (fname);
> +    }

Will this still allow loading from the usual places as well?

>    if (NULL == handle)
>      {
>        SCM fn;
> @@ -314,6 +349,8 @@
>    scm_tc16_dynamic_obj = scm_make_smob_type ("dynamic-object", 0);
>    scm_set_smob_mark (scm_tc16_dynamic_obj, dynl_obj_mark);
>    scm_set_smob_print (scm_tc16_dynamic_obj, dynl_obj_print);
> +  scm_loc_load_path = SCM_VARIABLE_LOC (scm_c_define
> ("%load-libpath", SCM_EOL));
> +  scm_init_load_libpath ();
>    sysdep_dynl_init ();
>  #include "libguile/dynl.x"
>  }
> diff -uNr guile-1.7.2.orig/libguile/Makefile.am guile-1.7.2/libguile/Makefile.am
> --- guile-1.7.2.orig/libguile/Makefile.am       2005-03-08
> 02:03:23.000000000 +0300
> +++ guile-1.7.2/libguile/Makefile.am    2005-09-18 23:23:44.000000000 +0400
> @@ -234,6 +234,9 @@
>         @echo '#define SCM_PKGDATA_DIR "$(pkgdatadir)"' >> libpath.tmp
>         @echo '#define SCM_LIBRARY_DIR
> "$(pkgdatadir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
>         @echo '#define SCM_SITE_DIR "$(pkgdatadir)/site"' >> libpath.tmp
> +       @echo '#define SCM_PKGLIB_DIR "$(pkglibdir)"' >> libpath.tmp
> +       @echo '#define SCM_LIB_DIR
> "$(pkglibdir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
> +       @echo '#define SCM_SITELIB_DIR "$(pkglibdir)/site"' >> libpath.tmp
>         @echo '#define SCM_BUILD_INFO { \' >> libpath.tmp
>         @echo ' { "srcdir", "'"`cd @srcdir@; pwd`"'" }, \' >> libpath.tmp
>         @echo ' { "top_srcdir",    "@top_srcdir_absolute@" }, \' >> libpath.tmp
> diff -uNr guile-1.7.2.orig/libguile/Makefile.in guile-1.7.2/libguile/Makefile.in
> --- guile-1.7.2.orig/libguile/Makefile.in       2005-03-08
> 03:42:07.000000000 +0300
> +++ guile-1.7.2/libguile/Makefile.in    2005-09-18 23:23:50.000000000 +0400
> @@ -1898,6 +1898,9 @@
>         @echo '#define SCM_PKGDATA_DIR "$(pkgdatadir)"' >> libpath.tmp
>         @echo '#define SCM_LIBRARY_DIR
> "$(pkgdatadir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
>         @echo '#define SCM_SITE_DIR "$(pkgdatadir)/site"' >> libpath.tmp
> +       @echo '#define SCM_PKGLIB_DIR "$(pkglibdir)"' >> libpath.tmp
> +       @echo '#define SCM_LIB_DIR
> "$(pkglibdir)/$(GUILE_EFFECTIVE_VERSION)"'>>libpath.tmp
> +       @echo '#define SCM_SITELIB_DIR "$(pkglibdir)/site"' >> libpath.tmp
>         @echo '#define SCM_BUILD_INFO { \' >> libpath.tmp
>         @echo ' { "srcdir", "'"`cd @srcdir@; pwd`"'" }, \' >> libpath.tmp
>         @echo ' { "top_srcdir",    "@top_srcdir_absolute@" }, \' >> libpath.tmp

Conclusion: this looks OK to me, but I'm not an expert on this
subject.  I recall previous threads on why it is (or is not) desirable
for all Guile libraries to go into /usr/local/lib or /usr/lib, but I
can't remember what the arguments were.

      Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

> >  static void *
> >  sysdep_dynl_link (const char *fname, const char *subr)
> >  {
> > -  lt_dlhandle handle;
> > -  handle = lt_dlopenext (fname);
> > +  lt_dlhandle handle = NULL;
> > +  SCM scm_search_path = scm_string_join (*scm_loc_load_path,
> > +                                        scm_from_locale_string (":"),
> > +                                        SCM_UNDEFINED/*scm_sym_infix*/);
> > +  char * search_path = scm_to_locale_string (scm_search_path);
> > +  scm_frame_free (search_path);
> > +  if (!lt_dlsetsearchpath (search_path))
> > +    {
> > +      handle = lt_dlopenext (fname);
> > +    }
>
> Will this still allow loading from the usual places as well?
>
Yes. http://www.gnu.org/software/libtool/manual.html#Libltdl-interface

If libltdl cannot find the library and the file name filename does not
have a directory component it will additionally search in the
following search paths for the module (in the order as follows):

   1. user-defined search path: This search path can be changed by the
program using the functions lt_dlsetsearchpath, lt_dladdsearchdir and
lt_dlinsertsearchdir.
   2. libltdl's search path: This search path is the value of the
environment variable LTDL_LIBRARY_PATH.
   3. system library search path: The system dependent library search
path (e.g. on Linux it is LD_LIBRARY_PATH).

In reality libltdl will search in user-defined search path first, then
in $LTDL_LIBRARY_PATH, then in $LD_LIBRARY_PATH, then in default path
(/lib then /usr/lib on linux), then finally in current directory. Good
from security viewpoint (of course from security viewpoint it'll be
the best to avoid current directory altogether, but.. we can not have
everything, right?).

> Conclusion: this looks OK to me, but I'm not an expert on this
> subject.  I recall previous threads on why it is (or is not) desirable
> for all Guile libraries to go into /usr/local/lib or /usr/lib, but I
> can't remember what the arguments were.

I'm not talking about GUILE libraries. I'm talking about EXTENSIONS
libraries. While GUILE libraries for different versions of GUILE can
happily live in /usr/lib (they have different API versions) this is
NOT true for the extensions: their SO-number is related to API of the
EXTENSION, not GUILE but this library is linked to GUILE library as
well. Thus - collisions. It's possible to avoid this probloem with
some hacks but... it's really better to just supply extension-writers
with sane place DIFFERENT for different versions of GUILE.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Thien-Thi Nguyen]

   From: Vorfeed Canal <vorfeed.canal@gmail.com>
   Date: Mon, 26 Sep 2005 20:34:16 +0400

   Hmm... And why "module catalogs" are superior ? I see one reason for
   their existence, but may be there are ones. For example I view this
   feature: "the actual placement of the file in the filesystem is
   decoupled from its module name" as DISadvantage... I mean: we need
   hierarchy of modules, we have perfect system to organize objects in
   hierarchy called "filesystem" why we'll ever want to replace it
   without very compelling reasons?

i think module catalogs are superior because they address some of your
concerns (which i recognize since similar thinking inspired the design
and implementation of the module catalog system).

perhaps you are not aware that module catalogs map module names (list of
symbols like: (ice-9 q)) to module implementations, which are actually
files in the filesystem?  the particular implementations supported are
currently scheme code and shared object libraries, the latter thanks to
libtool support in runtime and methodology.

iirc, in an earlier message you ask for user ability to specify things
(at runtime).  the decoupling mentioned is a clean way to effect that.

i will augment the docs to emphasize that the module catalog system does
not replace guile's historic resolution process (the end result of which
is always some file on the filesystem), but simply formalizes it (a bit)
and extends it (a bit) in a backward- and (i hope) upward-compatible
way.  thanks for showing me how the docs can cause misunderstanding.

   The biggest problem with this mechanism is that it's unsupported by
   official version.

if i can fix the problem of not having write privs, i can fix this
problem as well (but not having write privs is no longer my problem).

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Kevin Ryde]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> I'm not talking about GUILE libraries. I'm talking about EXTENSIONS
> libraries. While GUILE libraries for different versions of GUILE can
> happily live in /usr/lib (they have different API versions) this is
> NOT true for the extensions: their SO-number is related to API of the
> EXTENSION, not GUILE but this library is linked to GUILE library as
> well.

Simultaneously supporting multiple binary incompatible versions of
anything is painful.  I would say the best idea is "don't do that".

Subdirs of /usr/lib or versioned .so filenames can keep things apart
if you really want.  And that can be easily handled in the .scm when
loading.  The absense of a global convention is not the calamity you
assert.

> why
> project with over 8 years history STILL has such minor basic issues
> unresolved ? Are there are developers who can support GUILE or is it
> semi-abandoned project like HURD ?

Insults and rants are an excellent way to get someone to help you.
Actually describing what you're trying to do would be useless.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exceptions

[Ludovic Courtès]

Hi,

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> But what about GUILE extensions written in C ? Lack of sane
> place to put C glue libraries bothers me.

Extension libraries written in C can also be thought of as actual
libraries (for example, they may export C functions that wrap/unwrap
Scheme objects, or a C version of their Scheme API, etc.).  As such,
they deserve to be in the usual place for libraries.

> Not since this is such a big
> issue - it's minor issue.And THAT is reason it's bothering me: why
> project with over 8 years history STILL has such minor basic issues
> unresolved ? Are there are developers who can support GUILE or is it
> semi-abandoned project like HURD ?

Maybe you misunderstood the issues?

BTW, you should really try GNU/Hurd on your box before complaining.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/27/05, Kevin Ryde <user42@zip.com.au> wrote:
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
> >
> > I'm not talking about GUILE libraries. I'm talking about EXTENSIONS
> > libraries. While GUILE libraries for different versions of GUILE can
> > happily live in /usr/lib (they have different API versions) this is
> > NOT true for the extensions: their SO-number is related to API of the
> > EXTENSION, not GUILE but this library is linked to GUILE library as
> > well.
>
> Simultaneously supporting multiple binary incompatible versions of
> anything is painful.  I would say the best idea is "don't do that".
>
AND... what is your alternative ?

> Subdirs of /usr/lib or versioned .so filenames can keep things apart
> if you really want.

Yes, I do want this. Despite everything I was unable to move ALL
scripts from PHP 4.0 to PHP 5.0 "in one go" and I'm pretty sure there
will be the same situation in the future with guile 1.8 vs guile 1.10
or guile 2.0 or guile 3.0. Two different versions of anything in one
system is not a great sight but it's inevitable in a lot of
situations.

> And that can be easily handled in the .scm when loading.

WHEN ? When you've started writing your extension or when you already
installed hundred of them and now stumbled upon the need to separate
them ?

> The absense of a global convention is not the calamity you assert.
>
Of course not! Lack of the vision is calamity. Right now guile and
guile-ecosystem are small and all can be managed by hand despite lack
of planning. Once it'll have number of extensions comparable to CPAN
(i.e.: thusands or may be tens of thousands) it WILL BE calamity.

It's bad enough that GUILE 1.7.2 have default GUILE_SITE_DIR
"/usr/share/guile/site" while Perl 5.8.7 uses
"/usr/lib/perl5/site_perl/5.8.7" and Python 2.4.1 uses
"/usr/lib/python2.4/site-packages" (I like the python's approach the
best while perl's is barely acceptable but guile's one is worst of
them all), but this can be easily solved (trivial change to GUILE
sources - and all extensions will start to use
"/usr/share/guile-1.7/site"; no need to poke around with exntensions
sources) but more sad fact is that all extensions I've checked
(guile-gnome-platform, guile-simplesql,
guile-dbi/guile-dbd-mysql/guile-dbd-postgresql) keep all files for all
versions of GUILE in /usr/lib and it CAN NOT be easily solved with
changes in GUILE: there are no GUILE_SITE_DIR extensions are checking,
but instead everything is put in $prefix/lib: I'd be forced to fix
them all SEPARATELY! And KEEP then in such a state BY MYSELF! Ungh.

> > why
> > project with over 8 years history STILL has such minor basic issues
> > unresolved ? Are there are developers who can support GUILE or is it
> > semi-abandoned project like HURD ?
>
> Insults and rants are an excellent way to get someone to help you.
> Actually describing what you're trying to do would be useless.
>
Sigh. I fail to see why you need "actual description" when the problem
is the same as with GCC, AutoTools, Perl, PHP or any other similar
tool, discussed 10'000 times in different places and has single
obvious solution implemented by most serious tools out there.

But Ok. If you wish. Problem: I want to upgrade in the future without
major hassle. That's all.

Scenario is more or less the following:
1. Install GUILE 1.8 (or may be GUILE 1.10 or GUILE 2.0).
2. Install 1000 extensions for GUILE 1.8.
3. Upgrade to GUILE 2.0 (or GUILE 1.20 or GUILE 3.0) - extensions are
handled/recompiled by package manager (it's its work, after all).
4. Find that 10 projects (our of 10'000) are incompatible with new version.
5. Keep two versions for a while: GUILE 2.0 as default and GUILE 1.8
for few old projects.

See ? Minor issue becomes major one with time - it's question of
scale. If your answer: "if you system is not big in scale then ad-hoc
solutions will work and GUILE is not designed to handle big projects"
then I accept this answer and will try my luck with some other version
of scheme - or may be Python/Ruby/etc. Gosh! Minor projects are
perfectly supportable with PHP despite its shortcomings. Medium-sized
to big projects is where I have a problem: if project is big enough
then sooner or later you'll stumble upon the need to keep one part
with PHP 4.4.0, other with PHP 5.0.4 and still other with PHP 5.0.5
since PHP developers like to introduce frivolous changes in language
semantic in the middle of stable series. But if you can not even keep
two versions of tool+extensions sets for different projects then
you'll have the problem earlier (in fact problem is already with us:
Guile-PG is incompatible with GUILE 1.7.x right now; I was just lucky
to not use Guile-PG so far) - and with today's guile+extensions you
can not: GUILE will ONLY check "/lib" and "/usr/lib" for libraries (in
this order) - no matter where it's installed. And 1000 ad-hoc changes
in 1000 extnesions is not a good way to manage problem. We need either
"manager extension" (it's done this way in OCaml community: findlib is
not part of OCaml core but separete extension) and then everyone will
use it or (preferrable) complete support for extensions in core system
(this is done this way in Python, Perl, PHP and a lot of other
projects).


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/27/05, Thien-Thi Nguyen <ttn@glug.org> wrote:
>
>    Hmm... And why "module catalogs" are superior ? I see one reason for
>    their existence, but may be there are ones. For example I view this
>    feature: "the actual placement of the file in the filesystem is
>    decoupled from its module name" as DISadvantage... I mean: we need
>    hierarchy of modules, we have perfect system to organize objects in
>    hierarchy called "filesystem" why we'll ever want to replace it
>    without very compelling reasons?
>
> i think module catalogs are superior because they address some of your
> concerns (which i recognize since similar thinking inspired the design
> and implementation of the module catalog system).
>
I *DO* comprehend the need for something like this "in the bright
future" (after all translators must allow guile to use modules written
in list or TCL). But today... for just two possibilities (C glue code
and scheme sources) they look like much and too little in the same
time. Too much: we have two distinct things - stand-alone scheme
modules and non-stand-alone C glue code (:autoload is deprecated,
rememeber?). Plus C glue code is architecture-dependent (thus must be
in /usr/lib somewhere) while scheme code is not (so it must go in
/usr/share somewhere). Too little: there are no supports for
translators anyway (or I'm wrong and it IS possible to write module in
Logo?).

So I think for today simple search over two distinct lists (one for
architecture-dependent glue code and one for architecture-independent
scheme modules) are the best solution. Later when we'll have
translators and everything may be module catalogs will be usefull, but
not today.

> perhaps you are not aware that module catalogs map module names (list of
> symbols like: (ice-9 q)) to module implementations, which are actually
> files in the filesystem?

I *AM* aware. But I think that modules catalogs are overkill for what
is awailable today and not enough for what is really needed in the
future. Thus it's better to use simpler approach: less complexity and
more-or-less the same benefits. Once we'll have loadable translators
and everything related we'll need some more complex approach.

> the particular implementations supported are currently scheme code and shared object
> libraries, the latter thanks to libtool support in runtime and methodology.
>
And scheme code and shared object libraries are different enough to
make lumping them together rather impractical, while list and TCL are
not supported anyway - so what's the point ?

> iirc, in an earlier message you ask for user ability to specify things
> (at runtime).  the decoupling mentioned is a clean way to effect that.
>
I just want a way to keep all files related to some-big-project in
/usr/{lib,share}/same-big-project (unlike mess xchat-guile) and all
files related to guile x.y.z in /usr/{lib,share}/guile-something -
that's all. I do not think it's good idea to change the path on the
fly too often - more like part of initial setup + small extra (for
emergencies).

> i will augment the docs to emphasize that the module catalog system does
> not replace guile's historic resolution process (the end result of which
> is always some file on the filesystem), but simply formalizes it (a bit)
> and extends it (a bit) in a backward- and (i hope) upward-compatible
> way.  thanks for showing me how the docs can cause misunderstanding.
>
To be frank the main part of doc is not even module system
specification and/or something like this but answer on simple question
WHY?. Why guile 1.4.1.1xx was ever developed ? Why parts of it are not
included in later versions of guile (yes, I know it's unofficial - yet
GNU Emacs does include some reimplemented extensions from XEmacs, so
it's not THE reason). I was unable to find this in documentation (or
better yet on site) so I was sure guile 1.4.1.106 is just bugfix
release for modern compilers.

>    The biggest problem with this mechanism is that it's unsupported by
>    official version.
>
> if i can fix the problem of not having write privs, i can fix this
> problem as well (but not having write privs is no longer my problem).

It's my problem, right. Since guile 1.4 does not support some features
I want/need (GOOPS and pthreads are major ones) I can not use nice
things from your 1.4.1.1xx releases.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exceptions

[Vorfeed Canal]

On 9/27/05, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
> Hi,
>
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> > But what about GUILE extensions written in C ? Lack of sane
> > place to put C glue libraries bothers me.
>
> Extension libraries written in C can also be thought of as actual
> libraries (for example, they may export C functions that wrap/unwrap
> Scheme objects, or a C version of their Scheme API, etc.).  As such,
> they deserve to be in the usual place for libraries.
>
1. Not really:
  A. They are usually useless for programs not linked to guile - and
such programs will know where to find them anyway since libguile will
know this.
  B. If program A is linked to libguile.so.12 (guile 1.6.7) while
program B is linked to libguile.so.16 (guile 1.7.2) they'll need
DIFFERENT versions of such libraries - and this is somewhat
problematic with libtool.
  C. While it's true "these libraries can do this and they can do
that" in almost 100% cases today they just export some functions for
scheme level.
2. You can not install them "in the usual place" anyway:

$ ./configure --prefix=/somewhere/there ; make ; make install
$ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
ERROR: In procedure dynamic-link:
ERROR: file: "libguilereadline-v-16", message:
"libguilereadline-v-16.so: cannot open shared object file: No such
file or directory"

Oops ?

> > Not since this is such a big
> > issue - it's minor issue.And THAT is reason it's bothering me: why
> > project with over 8 years history STILL has such minor basic issues
> > unresolved ? Are there are developers who can support GUILE or is it
> > semi-abandoned project like HURD ?
>
> Maybe you misunderstood the issues?
>
I did not. Right now it's IMPOSSIBLE to install two versions of guile
at all - let alone in the sane way
(/usr/bin/guile-{1.6,1.7},/usr/lib/guile-{1.6,1.7},/usr/share/guile-{1.6,1.7}
so I can not see how guile development is done in first place (it's
standard practice to have 3-4 different versions of program while it's
in developmet and guile does not work this way at all - and even if
you'll fix guile itself third-party extensions will not obey your
decision).

> BTW, you should really try GNU/Hurd on your box before complaining.

I've tried it few years ago and back then it was not really usable:
was not able to even work with 10GiB partition. Today... It does not
even detect my SATA HDD in my NForce4-based system. May be I've used
too old version, of course... or did something wrong. Plus AFAIK even
today it's still "not recommended for production use" - after >10
years of development and I'm not really interested in OS development
(or for that matter GUILE development): I want something that WORKS.
NOW. It's Ok if I need to spend some time with tuning/fixing, but not
YEARS, sorry.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Thien-Thi Nguyen]

   From: Vorfeed Canal <vorfeed.canal@gmail.com>
   Date: Tue, 27 Sep 2005 14:11:47 +0400

   Too much: we have two distinct things - stand-alone scheme modules
   and non-stand-alone C glue code (:autoload is deprecated,
   rememeber?).

i'm afraid i can't share in this "we".  i use "standalone" shared object
libraries in cron-walk (part of ttn-do)[1], and in other places, all the
time, and guile 1.4.x does not deprecate #:autoload (as far as i can
tell).  for example (from cron-walk), the module `(database tmpfile)'
has this entry in ~/local/lib/guile/1.4.1.106/.module-catalog:

 ((database tmpfile)
  scm_init_module
  "scm_init_database_tmpfile_module"
  () . "/home/ttn/local/lib/guile/1.4.1.106/database/tmpfile.so.0.0.0")

when evaluating `(use-modules (database tmpfile))', there is exactly one
filesystem access, the dlopen of the tmpfile.so.0.0.0; "wrapper" scheme
code is not necessary.

   Plus C glue code is architecture-dependent (thus must be in /usr/lib
   somewhere) while scheme code is not (so it must go in /usr/share
   somewhere).

all modules distributed w/ guile 1.4.x are installed in arch-dependent
dirs, in anticipation of the eventuality of scheme->sofile compilation,
thus sidestepping this problem.  the point is, wherever you decide
additional modules should go, it's enough to update the module catalog
so that guile can find it.  this supports local policy, which is one of
our shared concerns.

   Too little: there are no supports for translators anyway
   (or I'm wrong and it IS possible to write module in Logo?).

here is the entry for module (ice-9 q), in the same module catalog:

 ((ice-9 q)
  . "/home/ttn/local/lib/guile/1.4.1.106/ice-9/q.scm")

you can see that its form differs from that of (database tmpfile).
essentially, a module's "implementation type" is one of the pieces of
metadata that is encoded in the module catalog.  this means that the
system is ready to support other types.  however, i will concede that
presently, the actual load operation (`load' vs `dlopen') to be used for
any particular implementation type is not yet specifiable.  so i agree
halfly.

   So I think for today simple search over two distinct lists (one for
   architecture-dependent glue code and one for architecture-independent
   scheme modules) are the best solution. Later when we'll have
   translators and everything may be module catalogs will be usefull, but
   not today.

is it not better to eliminate (or reduce) search?  why use find(1) when
you have locate(1)?

   I *AM* aware. But I think that modules catalogs are overkill for what
   is awailable today and not enough for what is really needed in the
   future. Thus it's better to use simpler approach: less complexity and
   more-or-less the same benefits. Once we'll have loadable translators
   and everything related we'll need some more complex approach.

the user pov sees no complexity:
(use-modules (ice-9 q) (database tmpfile))

complexity in implementation is another question.

   And scheme code and shared object libraries are different enough to
   make lumping them together rather impractical, while list and TCL are
   not supported anyway - so what's the point ?

in practice (from user pov), lumping them together works fine.

the point (in this case) is to advance the guile module system while
honoring the past (as opposed to spurning it), solving its problems by
generalizing the partial solutions (of the past) and then respecializing
them to apply to new domains.  when a problem is not yet solved, that's
an opportunity to hack.  obviously, there is still hack potential in
supporting logo (for example).

   To be frank the main part of doc is not even module system
   specification and/or something like this but answer on simple question
   WHY?. Why guile 1.4.1.1xx was ever developed ? Why parts of it are not
   included in later versions of guile (yes, I know it's unofficial - yet
   GNU Emacs does include some reimplemented extensions from XEmacs, so
   it's not THE reason). I was unable to find this in documentation (or
   better yet on site) so I was sure guile 1.4.1.106 is just bugfix
   release for modern compilers.

i'm still working on a writeup for these (very relevant) questions.  if
you're still around in spring/summer 2006 you'll probably see a post to
guile-user announcing it.  if not but you think you might be interested
anyway, let me know and i will cc you.

   It's my problem, right.

it is a problem/opportunity of the community and how it interacts.

   Since guile 1.4 does not support some features I want/need (GOOPS and
   pthreads are major ones) I can not use nice things from your
   1.4.1.1xx releases.

ok, i will no longer suggest guile 1.4.x for your situation.  instead i
suggest looking at the parts of it that you like and adding them in some
way or another to your methodology.  see [2] for work in this vein.

thi



[1] http://www.glug.org/people/ttn/software/ttn-do/
    http://www.glug.org/people/ttn/software/ttn-do/scm-html/cron-walk.scm.html.gz

[2] http://www.glug.org/people/ttn/software/guile-sdl/GUILE-FIXES


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/27/05, Thien-Thi Nguyen <ttn@glug.org> wrote:
>
> when evaluating `(use-modules (database tmpfile))', there is exactly one
> filesystem access, the dlopen of the tmpfile.so.0.0.0; "wrapper" scheme
> code is not necessary.
>
"One filesystem access" ? This *is* joke, right ? Dlopen of
tmpfile.so.0.0.0 is FAR from being "one filesystem access"! You will
need access to /lib/ld-linux.so.2 anyway and then it'll check for
/lib/libc.so.6 and so on - complex and not-so-fast process. You've
optimized minor part of the whole process (scan over few directories)
- even if you'll somehow optimize it totally away the whole process
will not be significally faster. And if you really need this last
5-10% of speed guile is wrong choice anyway.

>    Plus C glue code is architecture-dependent (thus must be in /usr/lib
>    somewhere) while scheme code is not (so it must go in /usr/share
>    somewhere).
>
> all modules distributed w/ guile 1.4.x are installed in arch-dependent
> dirs, in anticipation of the eventuality of scheme->sofile compilation,
> thus sidestepping this problem.

Is this scheme->sofile scheduled already ? Are we actully SURE it will
actually happen someday ? Who and when will write this thing ? If we
are not sure then all this conglomeration have a simple name:
premature optimization. And "premature optimization is the root of all
evil" (Donald E. Knuth).

> the point is, wherever you decide additional modules should go, it's enough
> to update the module catalog so that guile can find it.

Who or what will update the catalog ? What is the guarantee that
catalog will be kept in updated state ? Is it similar to tetex where
you can put file in /usr/share/texmf/tex directory and it'll be
happily ignored unless you'll rerun some obscure program ? This is
prime candidte for the "most hated misfeature of tetex" award in my
eyes...

> this supports local policy, which is one of our shared concerns.

It violates KISS and IMHO this is bigger problem."Keep solution as
simple as possible, but not simpler".

GUILE 1.7.2 fails the second part, no doubt about it (i.e.: this
solution is too simple thus does not really solve the problem):

$ ./configure --prefix=/somewhere/there ; make ; make install
$ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
ERROR: In procedure dynamic-link:
ERROR: file: "libguilereadline-v-16", message:
"libguilereadline-v-16.so: cannot open shared object file: No such
file or directory"

The question is: does your solution fail the first ?

> is it not better to eliminate (or reduce) search?  why use find(1) when
> you have locate(1)?
>
Funny for you to offer this anology. This is from my system:
-- cut --
$ man locate ; man slocate
No manual entry for locate
No manual entry for slocate
-- cut --
I'm using equery(1) and find(1) quite often, though. The first one
does answer the question: "where is this file MUST be?", the second
one "where is this file is NOW?" while locate answer the question
"where was this file 12 hours ago?" - and this is the question I
rarely (if ever) need to ask myself.

VFS *already* includes cache for filesystem (yes - both false
positives AND false negatives are cached), I do not need another one -
especially manually maintained one. I've seen A LOT OF such systems
(Tomcat, tetex, etc, etc). In 9 out of 10 cases speedup in negligible
while consistency problems are very real.

>    I *AM* aware. But I think that modules catalogs are overkill for what
>    is awailable today and not enough for what is really needed in the
>    future. Thus it's better to use simpler approach: less complexity and
>    more-or-less the same benefits. Once we'll have loadable translators
>    and everything related we'll need some more complex approach.
>
> the user pov sees no complexity:
> (use-modules (ice-9 q) (database tmpfile))
>
> complexity in implementation is another question.
>
No so fast. WHO is writing this entries:
-- cut --
((database tmpfile)
 scm_init_module
 "scm_init_database_tmpfile_module"
 () . "/home/ttn/local/lib/guile/1.4.1.106/database/tmpfile.so.0.0.0")
-- cut --
And when ? Who will change this entry from tmpfile.so.0.0.0 to
tmpfile.so.1.0.0 after API change ?

> ok, i will no longer suggest guile 1.4.x for your situation.  instead i
> suggest looking at the parts of it that you like and adding them in some
> way or another to your methodology.  see [2] for work in this vein.
>
Argh. I can hack my way around perfectly fine (my first mail to
mailing list contained working patch, after all - somewhat limited
"proof of concept" yet working). But then I'll be forced to repeat the
process for each and every extension I'll ever use! And THIS is what I
want to avoid. I agree it's more social problem then technical one,
but this is type of problem I'd like to avoid by switching from PHP to
GUILE. I do not like to see situation where "this thing works only
with PHP 4.4.0 but not with PHP 5.0 while that thing is not compatible
with PHP 5.0.0-5.0.4 but still other thing requires PHP 5.0.5". In
this light guile 1.4.1.1xx is VERY bad: it looks like we have
"official GUILE", then TTN GUILE, also there will be Vorfeed-GUILE (if
I'll decide to keep my own hack for my own use) and so on. Not a
pretty sight.

> [2] http://www.glug.org/people/ttn/software/guile-sdl/GUILE-FIXES
>
Now I'm officially confused. I've dowhnloaded
guile-1.6-missing-tools.tar.gz. Ok. Now I can produce "module
catalogs" (this is exactly what I want to avoid, but Ok) - yet there
are no way to actually USE them ? What good will it do for me ? Guile
still will load libraries from /lib and /usr/lib only and I still can
not keep libraries for two versions of guile in different places...


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exceptions

[Ludovic Courtès]

Hello,

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> 1. Not really:
>   A. They are usually useless for programs not linked to guile - and
> such programs will know where to find them anyway since libguile will
> know this.

Libguile knows where _any_ third party library (the shared object) gets
installed?  This is wrong.  The user knows it, the Scheme module that
loads it knows it, but Guile itself doesn't care.

>   B. If program A is linked to libguile.so.12 (guile 1.6.7) while
> program B is linked to libguile.so.16 (guile 1.7.2) they'll need
> DIFFERENT versions of such libraries - and this is somewhat
> problematic with libtool.

This is true I guess, because `dynamic-link' doesn't allow to specify
version info.  _This_ is an issue and maybe this procedure could be
fixed by allowing the user to pass Libtool-like version information.

Note that `(ice-9 readline)' works around this by having the library
name contain version information.

>   C. While it's true "these libraries can do this and they can do
> that" in almost 100% cases today they just export some functions for
> scheme level.

Maybe.  So what?

> 2. You can not install them "in the usual place" anyway:
>
> $ ./configure --prefix=/somewhere/there ; make ; make install
> $ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
> ERROR: In procedure dynamic-link:
> ERROR: file: "libguilereadline-v-16", message:
> "libguilereadline-v-16.so: cannot open shared object file: No such
> file or directory"
>
> Oops ?

That doesn't look so weird to me.  The convention on Unix systems is
that you _have to_ specify at run-time a list of directories where
libraries may be searched for by the loader.

> I did not. Right now it's IMPOSSIBLE to install two versions of guile
> at all - let alone in the sane way
> (/usr/bin/guile-{1.6,1.7},/usr/lib/guile-{1.6,1.7},/usr/share/guile-{1.6,1.7}

Debian has two Guile packages that may be installed together alongside.
Guile itself would work fine.  Even `(ice-9 readline)' will work fine
thanks to the workaround above.

The only thing (admittedly important!) that may not work, though, is
other extension libraries, as we noted above.

> so I can not see how guile development is done in first place (it's
> standard practice to have 3-4 different versions of program while it's
> in developmet and guile does not work this way at all - and even if
> you'll fix guile itself third-party extensions will not obey your
> decision).

This is true.  The point is that there is apparently no sufficient
manpower to address all these issues.  In particular, I guess the
current Guile developers work hard to improve Guile itself, at the
expense of breaking binary compatibility.

Note, however, that Guile 1.6 was compatible at the source-level with
Guile 1.4 (and people were greatly encourage to drop the `gh_'
interface), and Guile 1.7 is source-level compatible with Guile 1.6 (and
it also encourage users to migrate to the new API when relevant).

Apparently, the C API of Guile 1.7 was designed to me as much
``future-proof'' as possible, given the goals that can be envisioned
today.  The internals are no longer exposed to the C user.  I'm
confident in the relative stability of this API.

> I've tried it few years ago and back then it was not really usable:
> was not able to even work with 10GiB partition. Today... It does not
> even detect my SATA HDD in my NForce4-based system. May be I've used
> too old version, of course... or did something wrong. Plus AFAIK even
> today it's still "not recommended for production use" - after >10
> years of development and I'm not really interested in OS development
> (or for that matter GUILE development): I want something that WORKS.
> NOW. It's Ok if I need to spend some time with tuning/fixing, but not
> YEARS, sorry.

Why don't you sponsor a few developers, or even just a single one?

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Thien-Thi Nguyen]

   From: Vorfeed Canal <vorfeed.canal@gmail.com>
   Date: Tue, 27 Sep 2005 18:36:33 +0400

   "One filesystem access" ? This *is* joke, right ? Dlopen of
   tmpfile.so.0.0.0 is FAR from being "one filesystem access"! You will
   need access to /lib/ld-linux.so.2 anyway and then it'll check for
   /lib/libc.so.6 and so on - complex and not-so-fast process. You've
   optimized minor part of the whole process (scan over few directories)
   - even if you'll somehow optimize it totally away the whole process
   will not be significally faster. And if you really need this last
   5-10% of speed guile is wrong choice anyway.

i suppose "understatement" is more appropriate than "joke" for "one
filesystem access"; i don't count things outside guile's direct control.

   Is this scheme->sofile scheduled already ? Are we actully SURE it will
   actually happen someday ? Who and when will write this thing ? If we
   are not sure then all this conglomeration have a simple name:
   premature optimization. And "premature optimization is the root of all
   evil" (Donald E. Knuth).

compiling scheme to native is part of the original vision.  i don't know
what "scheduled" means, but i know that i'm personally interested in it
and that it is not out of my reach technically.  on the other hand, i'm
never sure about other people.

   Who or what will update the catalog ? What is the guarantee that
   catalog will be kept in updated state ? Is it similar to tetex where
   you can put file in /usr/share/texmf/tex directory and it'll be
   happily ignored unless you'll rerun some obscure program ? This is
   prime candidte for the "most hated misfeature of tetex" award in my
   eyes...

there is a tool to update the catalog.  the format is documented, so you
can even write your own tool if that fits in better w/ your methodology.

   > this supports local policy, which is one of our shared concerns.

   It violates KISS and IMHO this is bigger problem."Keep solution as
   simple as possible, but not simpler".

that is a nice way to think about things in the abstract.  i suppose if
the system exists and it works in practice, that is another nice way to
look at it.

   GUILE 1.7.2 fails the second part, no doubt about it (i.e.: this
   solution is too simple thus does not really solve the problem):

   $ ./configure --prefix=/somewhere/there ; make ; make install
   $ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
   ERROR: In procedure dynamic-link:
   ERROR: file: "libguilereadline-v-16", message:
   "libguilereadline-v-16.so: cannot open shared object file: No such
   file or directory"

   The question is: does your solution fail the first ?

i don't really know what "first" you are referring to here, but the code
is similar to the QUICK-START script from the Guile-SDL distribution dir.
you can try that out to see how things go.

   I'm using equery(1) and find(1) quite often, though. The first one
   does answer the question: "where is this file MUST be?", the second
   one "where is this file is NOW?" while locate answer the question
   "where was this file 12 hours ago?" - and this is the question I
   rarely (if ever) need to ask myself.

   VFS *already* includes cache for filesystem (yes - both false
   positives AND false negatives are cached), I do not need another one -
   especially manually maintained one. I've seen A LOT OF such systems
   (Tomcat, tetex, etc, etc). In 9 out of 10 cases speedup in negligible
   while consistency problems are very real.

i think you're missing the point: for files that don't move a lot (like
installed modules) caching the module name to filesystem location
mapping is an overall win.  if your installed modules move a lot, you
need a system where caching is easy to update and/or disable.  if you
judge the system by other criteria (such as implementation complexity),
you are allowing yourself to be distracted.

   No so fast. WHO is writing this entries:
   -- cut --
   ((database tmpfile)
    scm_init_module
    "scm_init_database_tmpfile_module"
    () . "/home/ttn/local/lib/guile/1.4.1.106/database/tmpfile.so.0.0.0")
   -- cut --
   And when ? Who will change this entry from tmpfile.so.0.0.0 to
   tmpfile.so.1.0.0 after API change ?

the short answer is: "make install".  for examples, please see
Makefile.am files in Guile-SDL and Guile-PG, as well as guile 1.4.x
top-level Makefile.am.

   Argh. I can hack my way around perfectly fine (my first mail to
   mailing list contained working patch, after all - somewhat limited
   "proof of concept" yet working). But then I'll be forced to repeat the
   process for each and every extension I'll ever use! And THIS is what I
   want to avoid.

when you are forced to repeat a process, it behooves you to codify it.
when you have community spirit, it's nice to share your code.  these are
the things i have done (i feel your pain, really!) and that you probably
will need to do to some extent.  why?  if you have no giant's shoulders
to stand on, that is an opportunity for you to become a giant yourself.

   I agree it's more social problem then technical one, but this is type
   of problem I'd like to avoid by switching from PHP to GUILE.

switching to guile will not help you avoid these problems. 

   I do not like to see situation where "this thing works only with PHP
   4.4.0 but not with PHP 5.0 while that thing is not compatible with
   PHP 5.0.0-5.0.4 but still other thing requires PHP 5.0.5". In this
   light guile 1.4.1.1xx is VERY bad: it looks like we have "official
   GUILE", then TTN GUILE, also there will be Vorfeed-GUILE (if I'll
   decide to keep my own hack for my own use) and so on. Not a pretty
   sight.

good or bad, guile 1.4.x is useful to me.  i hope it or parts of it can
be useful to you, but i cannot help you further than describing my own
thought processes as i believe them to coincide w/ yours.

   Now I'm officially confused. I've dowhnloaded
   guile-1.6-missing-tools.tar.gz. Ok. Now I can produce "module
   catalogs" (this is exactly what I want to avoid, but Ok) - yet there
   are no way to actually USE them ? What good will it do for me ? Guile
   still will load libraries from /lib and /usr/lib only and I still can
   not keep libraries for two versions of guile in different places...

how it will do you good is hard to predict.  it depends on your ability
to empathize as well as your ability to analyze what is there and to
realize what is not.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Exceptions

[Vorfeed Canal]

On 9/27/05, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
> Hello,
>
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> > 1. Not really:
> >   A. They are usually useless for programs not linked to guile - and
> > such programs will know where to find them anyway since libguile will
> > know this.
>
> Libguile knows where _any_ third party library (the shared object) gets
> installed?

Of course it must - how else can it load them ? With my patch it knows
about few default places and can be instructed about other places in
nice shemely way.

> This is wrong.  The user knows it, the Scheme module that
> loads it knows it, but Guile itself doesn't care.

... and as a result the whole system does not work. Yeah - this is
exactly what I see.

In our real imperfect world neither module creater nor user care about
libraries placement so it's obvious that guile should do this, there
are noone else. Module creator does not care since it's not really
important for him/her (it should be somewhere where guile can find it
- no other preferences usually), user has even less reasons to care
(he's just a user - why should he care?) and when libguile does not
care as well the whole thing breaks down.

The real strange thing is that libguile actually *knows* about
it:"guile-config info pkglibdir" will print correct information (true
for both GUILE 1.6.x and GUILE 1.7.x).
-- cut --
$ /somewhere/there/bin/guile-config info pkglibdir
/somewhere/there/lib/guile
-- cut --
it just never actually uses this knowleadge.

> >   B. If program A is linked to libguile.so.12 (guile 1.6.7) while
> > program B is linked to libguile.so.16 (guile 1.7.2) they'll need
> > DIFFERENT versions of such libraries - and this is somewhat
> > problematic with libtool.
>
> This is true I guess, because `dynamic-link' doesn't allow to specify
> version info.  _This_ is an issue and maybe this procedure could be
> fixed by allowing the user to pass Libtool-like version information.

This is one solution. And IMO not the best solution. If package DOES
HAVE pkglibdir (and GUILE has one - just check "guile-config info
pkglibdir" with GUILE 1.6.x and/or GUILE 1.7.x) then I should be able
to put my architecture-dependent file there without further dances!

> Note that `(ice-9 readline)' works around this by having the library
> name contain version information.

Are we on the same planet ? On my planet this:
-- cut --
$ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
ERROR: In procedure dynamic-link:
ERROR: file: "libguilereadline-v-16", message:
"libguilereadline-v-16.so: cannot open shared object file: No such
file or directory"
-- cut --
means that "(ice-9 readline) does not work".

> >   C. While it's true "these libraries can do this and they can do
> > that" in almost 100% cases today they just export some functions for
> > scheme level.
>
> Maybe.  So what?

IETF principle: It's better to have working code today then perfect
code "sometime in the future". Let's handle existing use-cases now,
then think about perfection. GUILE exists for 8 eyars yet still
mishandle common cases. May be it's time to stop worrying about
perfection ?

> > 2. You can not install them "in the usual place" anyway:
> >
> > $ ./configure --prefix=/somewhere/there ; make ; make install
> > $ /somewhere/there/bin/guile -e '(use-modules (ice-9 readline))'
> > ERROR: In procedure dynamic-link:
> > ERROR: file: "libguilereadline-v-16", message:
> > "libguilereadline-v-16.so: cannot open shared object file: No such
> > file or directory"
> >
> > Oops ?
>
> That doesn't look so weird to me.  The convention on Unix systems is
> that you _have to_ specify at run-time a list of directories where
> libraries may be searched for by the loader.
>
I *did*. When I configured GUILE I specified this info. If GUILE lost
it - it's not my problem.

> > I did not. Right now it's IMPOSSIBLE to install two versions of guile
> > at all - let alone in the sane way
> > (/usr/bin/guile-{1.6,1.7},/usr/lib/guile-{1.6,1.7},/usr/share/guile-{1.6,1.7}
>
> Debian has two Guile packages that may be installed together alongside.
> Guile itself would work fine.  Even `(ice-9 readline)' will work fine
> thanks to the workaround above.
>
Oh the infinite wisdom of RFC1925. Yes, "with sufficient thrust, pigs
fly just fine". But you forgot the next part: "However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead." Yes, it's possible to hack around GUILE's idiosyncrasies -
but I think my time will be better spent doing something else.

> The only thing (admittedly important!) that may not work, though, is
> other extension libraries, as we noted above.
>
And this is the problem I've started the thread with.

> > so I can not see how guile development is done in first place (it's
> > standard practice to have 3-4 different versions of program while it's
> > in developmet and guile does not work this way at all - and even if
> > you'll fix guile itself third-party extensions will not obey your
> > decision).
>
> This is true.  The point is that there is apparently no sufficient
> manpower to address all these issues.  In particular, I guess the
> current Guile developers work hard to improve Guile itself, at the
> expense of breaking binary compatibility.
>
...and without offering adequate tools for peacefull coexistence of
few GUILE versions. Brilliant decision. Just brilliant.

And this bullshit about lack of manpower is just that. Bullshit. I've
coded working solution in half-hour. It does not handle everything
(libguilereadline still goes to /somewhere/there/lib/, not to
/somewhere/there/lib/guile/1.7), but it's easy enough to fix. TTN
proposed something similar more then year ago. Yet GUILE still does
not have working solution.

> Note, however, that Guile 1.6 was compatible at the source-level with
> Guile 1.4 (and people were greatly encourage to drop the `gh_'
> interface), and Guile 1.7 is source-level compatible with Guile 1.6 (and
> it also encourage users to migrate to the new API when relevant).
>
This is what attracted me in first place, yes. Serious concerns about
binary-compatibility are great but if you are not offereing TOTAL
compatibility will ALL versions then you need some tool to keep few
versions around at the same time.

> Apparently, the C API of Guile 1.7 was designed to me as much
> ``future-proof'' as possible, given the goals that can be envisioned
> today.  The internals are no longer exposed to the C user.  I'm
> confident in the relative stability of this API.
>
Relative is operational word here.

> > I've tried it few years ago and back then it was not really usable:
> > was not able to even work with 10GiB partition. Today... It does not
> > even detect my SATA HDD in my NForce4-based system. May be I've used
> > too old version, of course... or did something wrong. Plus AFAIK even
> > today it's still "not recommended for production use" - after >10
> > years of development and I'm not really interested in OS development
> > (or for that matter GUILE development): I want something that WORKS.
> > NOW. It's Ok if I need to spend some time with tuning/fixing, but not
> > YEARS, sorry.
>
> Why don't you sponsor a few developers, or even just a single one?
>
Why should I ? I'm not univercity, science fund or Google to offer
sponsorship. I'm perfectly happy to offer what few hacks I've
developed/will develop for my own needs but if the only way to
acception is to create "perfect solution" then it's probably better to
try my luck elsewhere.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Vorfeed Canal]

On 9/27/05, Thien-Thi Nguyen <ttn@glug.org> wrote:
>
> compiling scheme to native is part of the original vision.  i don't know
> what "scheduled" means, but i know that i'm personally interested in it
> and that it is not out of my reach technically.  on the other hand, i'm
> never sure about other people.
>
Scheduled == we have this person who'll do coding after he'll do this or that.

>    It violates KISS and IMHO this is bigger problem."Keep solution as
>    simple as possible, but not simpler".
>
> that is a nice way to think about things in the abstract.  i suppose if
> the system exists and it works in practice, that is another nice way to
> look at it.
>
Ok, I still think this message-catalogs idea is needlessly complex,
but we can agree to disagree on that issue.

> i don't really know what "first" you are referring to here, but the code
> is similar to the QUICK-START script from the Guile-SDL distribution dir.
> you can try that out to see how things go.
>
Cite: "Keep solution as simple as possible, but not simpler" The first
part is first part: "keep you solution as simple as possible". I think
that your solution is too complex for today's needs and not complex
enough to tomorrows. But I'd be happy to have it in official GUILE as
well. I want *any* working solution there. Right now you can ask GUILE
about pkglibdir or libdir and it'll answer :
--
$ /somewhere/there/bin/guile-config info pkglibdir
/somewhere/there/lib/guile
$ /somewhere/there/bin/guile-config info libdir
/somewhere/there/lib
--
But it does not matter if you'll put your library in $pkglibdir or
$libdir - unless it's "/lib" or "/usr/lib" it'll not be found. This is
not acceptable IMNSHO. *Any* other WORKING solution is better then
non-working one.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: PHP to GUILE

[Thien-Thi Nguyen]

   From: Vorfeed Canal <vorfeed.canal@gmail.com>
   Date: Tue, 27 Sep 2005 21:47:26 +0400

   Ok, I still think this message-catalogs idea is needlessly complex,
   but we can agree to disagree on that issue.

ok.  i agree to disagree.

   I think that your solution is too complex for today's needs and not
   complex enough to tomorrows.

ok.  no worries, i will continue to use it and improve it (since it
works, after all).  maybe if/when you look at it in the future your
assessment will be different.

   But I'd be happy to have it in official GUILE as well.
   I want *any* working solution there.

i do not disagree.

   *Any* other WORKING solution is better then non-working one.

here it is your turn to understate.  you mean to say "any official (w/
pthreads and goops support)" instead of simply "any", since guile 1.4.x
fulfills the latter but you reject it.  it's important to figure out how
much relative importance you give to these attributes.  for my practice,
i find "official" carries little benefit (and a lot of hea{d,rt}-ache).
YMMV.

anyway, to bow out of this thread, i invite you (or anyone interested)
to hack guile 1.4.x to add pthreads and goops support.

thi


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Managing Guile and extensions versions

[Ludovic Courtès]

Hi,

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> Of course it must - how else can it load them ? With my patch it knows
> about few default places and can be instructed about other places in
> nice shemely way.

Yes, your patch seems to be one possible solution.  However, why not use
`pkglibdir' (versionizing it) which you mentioned in earlier posts
instead of this new directory?

The other thing needed, which you also mentioned earlier, is to have a
versionized site directory.  I've actually always wondered why this one
was not versioned.

>> This is true I guess, because `dynamic-link' doesn't allow to specify
>> version info.  _This_ is an issue and maybe this procedure could be
>> fixed by allowing the user to pass Libtool-like version information.
>
> This is one solution. And IMO not the best solution.

That's a solution to one of the two problems, the two problems being:

1.  Separating C libraries that are written for different versions of
    Guile, allowing to have versions of the same extension written for
    different Guile versions to coexist;

2.  Allowing to have different versions of a given extension for a same
    version of Guile.

Your patch addresses (1).  This `dynamic-link' thing could be used to
address (2).  It could be used to address (1) instead, but certainly not
both of them.  Anyway, we'd first need `libltdl' to allow for such
things.  I started to ask the Libtool people about this:
http://lists.gnu.org/archive/html/libtool/2005-09/msg00118.html .

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Vorfeed Canal]

On 9/28/05, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
> Hi,
>
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> > Of course it must - how else can it load them ? With my patch it knows
> > about few default places and can be instructed about other places in
> > nice shemely way.
>
> Yes, your patch seems to be one possible solution.  However, why not use
> `pkglibdir' (versionizing it) which you mentioned in earlier posts
> instead of this new directory?
>
1. I *am* using pkglibdir - take closer look on patch.
2. It's mostly matter of taste.
  A. Apache and PHP are using one directory
  B. Python and Ruby - two:
    one - for system packages and things installed with package manager
    anouther - for manually installed things, kinda /usr vs /usr/local
  C. Emacs - three:
    one - for bundled files
    one - for universal packages: /usr/share/emacs/site-lisp
    one for specific packages: vs /usr/share/emacs/21.4/site-lisp
  D. Perl - three but for different reasons:
    bundled things will go to /usr/lib/perl5/5.8.6/i686-linux
    package-installed things will go to
/usr/lib/perl5/vendor_perl/5.8.6/i686-linux
    manually-installed - to /usr/lib/perl5/site_perl/5.8.6/i686-linux
3. Guile itself already have %load_path for scheme_extensions and it
looks like this:
  $ guile -c '(display %load-path)'
  (/usr/share/guile/site /usr/share/guile/1.7 /usr/share/guile)
  I think the right idea is to keep list similar in structure.
4. Actual contents of default directory list is not important. Only
two requirements:
  A. It must not be empty  - this way there are place to put default
libraries like readline.
  B. It must be modifyable at runtime - this way complex program (like
Gnumeric or
      Gnucash) can keep it's private libraries private and not pollute
default directory.

In short: do not bother too much with understanding of my default
locations choice.

As long as there are some macros defined guile.m4 suitable for putting
in configure.ac I (as extension writer) will be happy. Exact place
where my libraries will be kept not as important: configure will
determine place, Makefile.am will put libraries there, guile will load
them - I'm not really interested in such morbid details, just in the
end result.

Application writer is interested in configurability (I want to add my
own private directory to the list and still keep the ability to load
library from "standard place"), again: what is stored in "standard
places list" is not interesting (as long as SOMETHING stored there).

> The other thing needed, which you also mentioned earlier, is to have a
> versionized site directory.  I've actually always wondered why this one
> was not versioned.
>
I did so as well, but surprisingly it's VERY minor issue: since it's
determined by GUILE_SITE_DIR and then by guile-config you can change
this default quite easily WITHOUT changing third-part extensions code!
And you already can call configure as
GUILE=/usr/bin/guile-1.4 GUILE_CONFIG=/usr/bin/guile-config-1.4
GUILE_TOOLS=/usr/bin/guile_tools ./configure ...

This means only architecture-depenent libraries generated by
third-party modules can not be easily handled...

> >> This is true I guess, because `dynamic-link' doesn't allow to specify
> >> version info.  _This_ is an issue and maybe this procedure could be
> >> fixed by allowing the user to pass Libtool-like version information.
> >
> > This is one solution. And IMO not the best solution.
>
> That's a solution to one of the two problems, the two problems being:
>
> 1.  Separating C libraries that are written for different versions of
>     Guile, allowing to have versions of the same extension written for
>     different Guile versions to coexist;
>
> 2.  Allowing to have different versions of a given extension for a same
>     version of Guile.
>
> Your patch addresses (1).  This `dynamic-link' thing could be used to
> address (2).  It could be used to address (1) instead, but certainly not
> both of them.

Nope. You *can* *not* use them to solve (1). Trivial REAL WORLD
sample: university system where you can only install stuff in your own
home directory.

> Anyway, we'd first need `libltdl' to allow for such  things.
> I started to ask the Libtool people about this:
> http://lists.gnu.org/archive/html/libtool/2005-09/msg00118.html .
>
Yes, it'd be quite nice to allow both (1) and (2). But!
1. It'll require major redesign or libtool (actual shared library is
versioned, but .la file is not).
2. Crude yet effective substitute usually enough: just add something
like "v2" to name of extension (like glib vs glib2). Not elegant but
it works...

In fact I'm not even sure this problem need solution! Think about it:
if we'll allow this we should allow two version of, for example (web
serialize) module. This means we'll be forced to develop some
versioning for scheme modules as well. A lot of work for unknown
benefit: in RARE cases where you really need two versions of the same
module you can cope with %load-path/%load-libpath tricks.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Ludovic Courtès]

Hi Vorfeed,

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> 4. Actual contents of default directory list is not important. Only
> two requirements:
>   A. It must not be empty  - this way there are place to put default
> libraries like readline.
>   B. It must be modifyable at runtime - this way complex program (like
> Gnumeric or
>       Gnucash) can keep it's private libraries private and not pollute
> default directory.

Right.

> In short: do not bother too much with understanding of my default
> locations choice.

Sure.

So, I'm all in favor of having your patch (or something equivalent)
applied.  I guess you'll need to /kindly/ ask the developers for further
reviewing and see what needs to be done so that it can actually be
applied.

> I did so as well, but surprisingly it's VERY minor issue: since it's
> determined by GUILE_SITE_DIR and then by guile-config you can change
> this default quite easily WITHOUT changing third-part extensions code!

This is true since `GUILE_SITE_DIR' is already widely used.  In fact,
the right way to do it would probably be to have:

1.  `%site-dir' (and obviously `GUILE_SITE_DIR') return
    `${datadir}/guile/MAJOR.MINOR/site';

2.  `%load-path' include both `${datadir}/guile/MAJOR.MINOR/site' _and_
    `${datadir}/guile/site' (in this order).

> Nope. You *can* *not* use them to solve (1). Trivial REAL WORLD
> sample: university system where you can only install stuff in your own
> home directory.

Yes you can: have third-party C libraries use Guile's version info.
IOW, add `-version-info
$LIBGUILE_INTERFACE_CURRENT:$LIBGUILE_INTERFACE_REVISION:$LIBGUILE_INTERFACE_AGE'
to your LDFLAGS.

However, this would not permit extension developers to use
`-version-info' for their own versioning purposes, so it sucks.

> Yes, it'd be quite nice to allow both (1) and (2). But!
> 1. It'll require major redesign or libtool (actual shared library is
> versioned, but .la file is not).

I don't think so but that discussion belongs to `libtool@'.

> 2. Crude yet effective substitute usually enough: just add something
> like "v2" to name of extension (like glib vs glib2). Not elegant but
> it works...

Remember: that's what `libguile-readline' already does.  You might want
to re-read your email answer to my suggesting such workarounds.  :-)

> In fact I'm not even sure this problem need solution! Think about it:
> if we'll allow this we should allow two version of, for example (web
> serialize) module. This means we'll be forced to develop some
> versioning for scheme modules as well. A lot of work for unknown
> benefit: in RARE cases where you really need two versions of the same
> module you can cope with %load-path/%load-libpath tricks.

"Lack of vision" you said earlier, right?

I believe Scheme module versioning would be beneficial, although I have
lived without it so far.  Anyway, a quite straightforward solution (at
first sight, at least) would be something like:

  (define-module (my-module)
    #:version/current 2
    #:version/age 1
    #:version/revision 4)

And:

  (use-modules ((my-module) #:interface 1))

This would look for `my-module.scm' in the directories of `%load-path'
and only import bindings from the first one (for instance) that
implements version 1 of the interface, in pure Libtool style.  And
AFAICS, this wouldn't introduce any compatibility issue: both versioned
and unversioned modules and module users could peacefully coexist.

That may add some overhead in the rare case where a significant number
of different versions of a module are available, since Guile needs to
load each module before knowing whether it matches the constraint.

Hmm...  In fact, that may be much more complicated than it seems since
`resolve-module' relies on `nested-ref' to find a module, and since
there can only be one module bound to a given name...

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Vorfeed Canal]

On 9/29/05, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:

> > In short: do not bother too much with understanding of my default
> > locations choice.
>
> Sure.
>
> So, I'm all in favor of having your patch (or something equivalent)
> applied.  I guess you'll need to /kindly/ ask the developers for further
> reviewing and see what needs to be done so that it can actually be
> applied.
>
Where are how should I do this ? I was under impression that this list
is exactly where such changes must be discussed.

> > I did so as well, but surprisingly it's VERY minor issue: since it's
> > determined by GUILE_SITE_DIR and then by guile-config you can change
> > this default quite easily WITHOUT changing third-part extensions code!
>
> This is true since `GUILE_SITE_DIR' is already widely used.  In fact,
> the right way to do it would probably be to have:
>
> 1.  `%site-dir' (and obviously `GUILE_SITE_DIR') return
>     `${datadir}/guile/MAJOR.MINOR/site';
>
> 2.  `%load-path' include both `${datadir}/guile/MAJOR.MINOR/site' _and_
>     `${datadir}/guile/site' (in this order).
>
...and since GUILE_SITE_DIR is already used by extensions developers
it can be done by Debian, Gentoo or RedHat packagers. No need to lump
different solutions together.

> > Nope. You *can* *not* use them to solve (1). Trivial REAL WORLD
> > sample: university system where you can only install stuff in your own
> > home directory.
>
> Yes you can: have third-party C libraries use Guile's version info.
> IOW, add `-version-info
> $LIBGUILE_INTERFACE_CURRENT:$LIBGUILE_INTERFACE_REVISION:$LIBGUILE_INTERFACE_AGE'
> to your LDFLAGS.
>
How can it solve ANYTHING ? Guile WILL NOT scan anything besides /lib
and /usr/lib (in that order) - even if you'll install it in
/home/canal/my-guile ! Yes, you can play with LTDL_LIBRARY_PATH and
LD_LIBRARY_PATH and do some other hacks - but this is hardly "clean
solution for the problem". And once GUILE can load libraries from
/home/canal/my-guile/lib you can use the same mechanism to solve
multiple installations problem.

> However, this would not permit extension developers to use
> `-version-info' for their own versioning purposes, so it sucks.
>
See above: even with `-version-info' you still must alter libltdl
search path and if you've done this you can use `-version-info' for
some other purpose.

> > 2. Crude yet effective substitute usually enough: just add something
> > like "v2" to name of extension (like glib vs glib2). Not elegant but
> > it works...
>
> Remember: that's what `libguile-readline' already does.  You might want
> to re-read your email answer to my suggesting such workarounds.  :-)
>
Not really - you can only use libguile-readline with the same version
of guile, so it's solution for the first probem (and it does not
really work as I've shown earlier).

> > In fact I'm not even sure this problem need solution! Think about it:
> > if we'll allow this we should allow two version of, for example (web
> > serialize) module. This means we'll be forced to develop some
> > versioning for scheme modules as well. A lot of work for unknown
> > benefit: in RARE cases where you really need two versions of the same
> > module you can cope with %load-path/%load-libpath tricks.
>
> "Lack of vision" you said earlier, right?
>
Nope. Just simple work/benefits check.

[some rants are skipped]

> Hmm...  In fact, that may be much more complicated than it seems since
> `resolve-module' relies on `nested-ref' to find a module, and since
> there can only be one module bound to a given name...

There are a lot of problems to be solved to make versioned modules
usable. While idea in general is not bad it'll require deep rework of
Guile internals, this is not 2-3 hours hack! So this is the case where
you can safely blame lack of manpower.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> Anyway, we'd first need `libltdl' to allow for such things.

Remember if you want to call a C code module directly from a C
mainline then you need something the ordinary loader can cope with
too.

(If setting up something clean and portable for this stuff was easy it
would have already been done.)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> Remember if you want to call a C code module directly from a C
> mainline then you need something the ordinary loader can cope with
> too.
>
> (If setting up something clean and portable for this stuff was easy it
> would have already been done.)

You're talking about loading the right version of shared library, right?

In fact, Libtool's versioning mechanism already makes this possible for
programs: the loader and/or dynamic linker chooses the one version of
the library the program expects to be linked against.

As for the `dlopen' equivalent to this, intuitively, I can't think of
any reason not to allow this (my understanding of the problem might be
too poor though).  For instance, `dlopen ("/lib/mylib.so.2.3.4")' does
load a specific version of the lib, but in a non-portable and unclear
way.  `libltdl' could provide a higher-level, portable API to do such
things.

But again, we're getting a bit off-topic.  ;-)

(However, I'd be glad to hear your thoughts about adding support for
versioning to Guile's module system.)

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Neil Jerram]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:

> On 9/29/05, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
>
>> So, I'm all in favor of having your patch (or something equivalent)
>> applied.  I guess you'll need to /kindly/ ask the developers for further
>> reviewing and see what needs to be done so that it can actually be
>> applied.
>>
> Where are how should I do this ? I was under impression that this list
> is exactly where such changes must be discussed.

The two developers who have thought most on this subject in the past
are Marius (Vollmer) and Rob (Browning), and they've both been out of
circulation for the last week or so.  No doubt one of them will
respond when they catch up with the list.

        Neil




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Kevin Ryde]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
> In fact, Libtool's versioning mechanism already makes this possible for
> programs: the loader and/or dynamic linker chooses the one version of
> the library the program expects to be linked against.

Oh, well, libtool only wraps what ld.so does, but yes.

> For instance, `dlopen ("/lib/mylib.so.2.3.4")' does
> load a specific version of the lib, but in a non-portable and unclear
> way.  `libltdl' could provide a higher-level, portable API to do such
> things.

I think difficulties with two .la's at the same time has been a
more-or-less known issue for quite a while.  There may be plans afoot,
but you might have observed the pace of libtool development is, well,
glacial.  (No disrespect to the libtool developers, it's a big and
arcane beast.)

> (However, I'd be glad to hear your thoughts about adding support for
> versioning to Guile's module system.)

I believe it needs very careful thought, because it's about planning
for or imagining what the future will look like, something that's far
from settled.

A system of versions virtually concedes that compatibility won't be
maintained, and that some kind of perpetual revision or at least
rebuilding of modules will be necessary.  It'd be better if that could
be avoided.

I think the present seems worse than it is, because the last couple of
releases have had a lot of changes.  If it settles down then the need
to version stuff like crazy ought to vanish.

The doco for the present is pretty light-on though.  Perhaps only
power-users have gone beyond the basics. :-)  I'm not aware of any
outright show-stoppers in the code though, not for any sensible sort
of arrangement.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Kevin Ryde]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> Easy: there are no easy
> way to install two snaphots of GUILE side-by-side. So such a need is
> quite real (unless development will be frozen totally).

The developers manage.  Even I manage to run 3 versions.

[guile-gnome env var setups]
> is *NOT* a good solution.

It doesn't seem terrific to me either.  scm files outside any known
location will have to have a load-path addition, but after that it
oughtn't need to mung LD_LIBRARY_PATH for private C code.  The
author/current-maintainer of guile-gnome is a smart guy and may have
concluded it's enough for normal install, including debian packages.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Ludovic Courtès]

Kevin Ryde <user42@zip.com.au> writes:

> I think difficulties with two .la's at the same time has been a
> more-or-less known issue for quite a while.  There may be plans afoot,
> but you might have observed the pace of libtool development is, well,
> glacial.  (No disrespect to the libtool developers, it's a big and
> arcane beast.)

Right (but I'm under the impression that Libtool releases are more
frequent than Guile releases ;-)).

> I believe it needs very careful thought, because it's about planning
> for or imagining what the future will look like, something that's far
> from settled.
>
> A system of versions virtually concedes that compatibility won't be
> maintained, and that some kind of perpetual revision or at least
> rebuilding of modules will be necessary.  It'd be better if that could
> be avoided.

Sure.  But while Guile developers can do their best to ensure that
Guile's modules don't change much over time, one cannot assume that
users of Guile won't ever need some versioning.

In actuality, versioning is something people have been expecting when
writing C code (and Libtool helps with this), and it's something which
other run-time supports, like Guile, should provide IMO.  Most of the
time, when one defines an API, be it in C or in Scheme, they cannot
guarantee that it won't ever change.

> I think the present seems worse than it is, because the last couple of
> releases have had a lot of changes.  If it settles down then the need
> to version stuff like crazy ought to vanish.

Right, but you're talking of Guile itself.

> The doco for the present is pretty light-on though.  Perhaps only
> power-users have gone beyond the basics. :-)  I'm not aware of any
> outright show-stoppers in the code though, not for any sensible sort
> of arrangement.

I'm not sure what you're talking about here.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Vorfeed Canal]

On 10/3/05, Kevin Ryde <user42@zip.com.au> wrote:
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
> >
> > Easy: there are no easy
> > way to install two snaphots of GUILE side-by-side. So such a need is
> > quite real (unless development will be frozen totally).
>
> The developers manage.  Even I manage to run 3 versions.
>
And this proves... exactly what ? Your ability to jump through hoops ?

When computers are concerned there are rarely exist a case where
"something is impossible" - usually it's "quite hard and error-prone".
Environment variables are exactly that: hard and error-prone (hard:
since they do different things on different systems and error-prone
since you must specify installation path two times in different
places: manual information duplication is the great way to
frustration).

> [guile-gnome env var setups]
>
And then add some program where guile is embedded as library to the
mix and see the mess where two interpreters are loaded from two
libraries. Been there seen that, no need to repeat the experience.

> > is *NOT* a good solution.
>
> It doesn't seem terrific to me either.  scm files outside any known
> location will have to have a load-path addition, but after that it
> oughtn't need to mung LD_LIBRARY_PATH for private C code.

Exactly. Why the hell scm files are managed via scheme variable but C
modules - via system-dependent variable! LD_LIBRARY_PATH is linux'ism,
it can be DYLD_LIBRARY_PATH LD_LIBRARY_PATH, LIBPATH, LIBRARY_PATH or
SHLIB_PATH in different unix'es. Looks like a big mess to me.

Plus *nothing* is written in Guile manuals about all this at all!
Kinda strange for languages poised as "extensions language".

> The author/current-maintainer of guile-gnome is a smart guy and may have
> concluded it's enough for normal install, including debian packages.
>
guile-gnome maintainer did what he thought is right, guile-pg did
different thing and so on. They all are "sensible" in some way but
since there are no single "official way" to handle this situation
different packages are doing different things. This is small problem
now, but if not eliminated it'll grow and make life harder and harder
for distributors (who tend to avoid guile packages even now) and users
(who are confused enough as it is).


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Kevin Ryde]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> LD_LIBRARY_PATH is linux'ism,

Actually I believe it comes from svr4 (maybe earlier too, not sure).

(Incidentally, nobody can tell if you're asking a question, advocating
your particular change, expressing new-user frustration, or just
generally banging on.  If you post something straightforward you might
get an answer.)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Vorfeed Canal]

On 10/5/05, Kevin Ryde <user42@zip.com.au> wrote:
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
> >
> > LD_LIBRARY_PATH is linux'ism,
>
> Actually I believe it comes from svr4 (maybe earlier too, not sure).
>
> (Incidentally, nobody can tell if you're asking a question, advocating
> your particular change, expressing new-user frustration, or just
> generally banging on.  If you post something straightforward you might
> get an answer.)

I had two major griefs (poor exceptions handling and poor handling of
C-based extensions) and one is adressed already: SRFI-34. Not exactly
the solution I've envisioned but acceptable alternative. Ok. But what
to do with C-based modules ?

You want straightforward question ? Can do. HOW TO do the
my-extension-0.0.tar.gz to make the following possible:

$ (
>  tar xzSvpf guile-1.7.2.tar.gz
>  cd guile-1.7.2
> ./configure --prefix=/myexperiments/guile
> make
> make install )
$ (
> tar xzSvpf my-extension-0.0.tar.gz
> cd my-extension-0.0
> GUILE=/myexperiments/guile/bin/guile \
> GUILE_CONFIG=/myexperiments/guile/bin/guile-config \
> GUILE_TOOLS=/myexperiments/guile/bin/guile-tools \
> ./configure
> make
> make install )
$ /myexperiments/guile/bin/guile -c '(use myextension modulename) ...'

Basically: I want to treat GUILE *and* GUILE extensions like normal
GNU packages. The one which respects --prefix parameters and/or
configuration variables like GUILE_CONFIG.

I *do* know how to do this with pure-scheme modules. I do *not* know
sane way to do this with C-based modules (yes, I can play with
LD_LIBRARY_PATH, wrappers and so on - IMO this is just insane: why the
hell we even have guile-config program if it can not be used to do
such a simple things).

I proposed some changes to make it possible. I do not really care if
my changes or some others will be accepted - I only want HOW TO for
my-extension-0.0.tar.gz, that's all.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Kevin Ryde]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
>> GUILE=/myexperiments/guile/bin/guile \
>> GUILE_CONFIG=/myexperiments/guile/bin/guile-config \
>> GUILE_TOOLS=/myexperiments/guile/bin/guile-tools \

I would set the PATH, this probably works though.

> $ /myexperiments/guile/bin/guile -c '(use myextension modulename) ...'

The short answer is: nothing special.

To run guile from a non-default location (anywhere except /usr I
think), I believe you need to put the new libdir into
LTDL_LIBRARY_PATH.  This is so guile can find its own C code modules.
Having set that it will find extensions like yours too.

The alternative, as I said, is to have your scm know the libdir you
were configured with.  This has the advantage of working if the user
installs your code to a different prefix than guile.  (Which may be
unlikely, but is quite possible.)

(Indicentally, I think guile should know its own libdir and know to
look there.  But a non-standard location is just that,
ie. non-standard, so it's not totally unreasonable to have to tell the
linking process about it.)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Vorfeed Canal]

On 10/9/05, Kevin Ryde <user42@zip.com.au> wrote:
> Vorfeed Canal <vorfeed.canal@gmail.com> writes:
> >
> >> GUILE=/myexperiments/guile/bin/guile \
> >> GUILE_CONFIG=/myexperiments/guile/bin/guile-config \
> >> GUILE_TOOLS=/myexperiments/guile/bin/guile-tools \
>
> I would set the PATH, this probably works though.

This is how it should work. I used GUILE/GUILE_CONFIG/GUILE_TOOLS and
not path since the next question will be "now what I need to do to
install guile 1.8.1 as /usr/bin/guile-1.8.1 and guile 1.8.2 as
/usr/bin/guile-1.8.2" (perl/php/python/ruby/tcl style).

The question is HOW IT SHOULD WORK! Where configure.ac/Makefile.am
should put libmysuperextension.la (+ .so, etc) file ? WHAT should I
write there ?

Can you show minimal GUILE extension layout ? Something trivial:
export one function uuid_generate_random from libuuid to scheme level.

> > $ /myexperiments/guile/bin/guile -c '(use myextension modulename) ...'
>
> The short answer is: nothing special.
>
Huh ? How guile will find my library then ?

Or do you mean I should duplicate all this information by hand for
each and every extension and THAT is called "nothing special" ?

> To run guile from a non-default location (anywhere except /usr I
> think), I believe you need to put the new libdir into
> LTDL_LIBRARY_PATH.  This is so guile can find its own C code modules.
> Having set that it will find extensions like yours too.
>
Yeah, it's even written in INSTALL file - but all this will work only
if I'll create my extension "in the right way", right ? If this "right
way" DOES exist then why existing extensions (like
guile-gnome-platform, Gnome-PG and so on) are not using this
mechanism. If this "right way" DOES NOT EXIST then why it does not
exist ?

> The alternative, as I said, is to have your scm know the libdir you
> were configured with.  This has the advantage of working if the user
> installs your code to a different prefix than guile.  (Which may be
> unlikely, but is quite possible.)
>
I can embed thousand and one hacks in my .scm file, true. This is NOT
what I want. I want simple solution - I've tried to find it in sources
of existing extensions but was unable to :-(

> (Indicentally, I think guile should know its own libdir and know to
> look there.  But a non-standard location is just that,
> ie. non-standard, so it's not totally unreasonable to have to tell the
> linking process about it.)
>
This is EXACTLY the problem: no matter what and how GUILE knows about
exactly two places: /usr/lib and /lib. No matter where it installed.

INSTALL file explains how this information is supposed to be delivered
to libltdl (with LD_LIBRARY_PATH). No information about how this
information is supposed to be found by configure.ac/Makefile.am in
extension. Neither in documentation of guile nor in code of existing
extensions.

IMNSHO this is insane:

  LD_LIBRARY_PATH=/opt/guile/lib \
    PATH=/opt/guile/bin:"${PATH}" \
      guile --version

But ok - at least it's documented. But what to do with extensions ?
WHAT is proposed solution ? WHEN this solution will be used by
real-life extensions like guile-gnome-platform ?


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Greg Troxel]

  INSTALL file explains how this information is supposed to be delivered
  to libltdl (with LD_LIBRARY_PATH). No information about how this
  information is supposed to be found by configure.ac/Makefile.am in
  extension. Neither in documentation of guile nor in code of existing
  extensions.

  IMNSHO this is insane:

    LD_LIBRARY_PATH=/opt/guile/lib \
      PATH=/opt/guile/bin:"${PATH}" \
        guile --version

I concur that this is a problem, and I think it's not impossible to
solve.  It is somewhat difficult, though, because of several
conflicting guidelines:

  debian doesn't allow setting RPATH, or at least used to not.  I've
  never really understood this.

  Many people think setting LD_LIBRARY_PATH is bletcherous.

  guile used to support binary-only modules, but I think after 1.6
  this compat support was dropped.  ttn-guile 1.4 still does.

My view is that when a program is compiled with --prefix=/foo that
when parts of it need to open files they should use absolute paths
with /foo so that exactly the right bits are obtained, regardless of
what is in the environment and path.  This means that you can't build
to /foo and then install in /bar, but IMHO that's one of the reasons
why we have source code.  (But, I'm afraid that this may run afoul of
the underlying reasons why debian doesn't like rpath.)

So, when I make extension modules that have binary libraries, I make a
foo.scm.in and put in it code like this:

;; Find our shared library (autoconf substitution).
(define *sinew-udaanlsu-libdir* "@prefix@/lib")

;; Link shlib, and initialize it.
(dynamic-call
 "guile_udaanlsu_init"
 (dynamic-link (string-append *sinew-udaanlsu-libdir* "/" "libguile_udaanlsu")))

Also, I use -R when linking, so the libraries can find other
libraries.  This is standard practice in NetBSD pkgsrc, but we of
course need to arrive at a solution that can work for all reasonable
practices.  I think it's reasonable for people that decline to use
rpath to have to use LD_LIBRARY_PATH.


-- 
        Greg Troxel <gdt@ir.bbn.com>


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Kevin Ryde]

Vorfeed Canal <vorfeed.canal@gmail.com> writes:
>
> "now what I need to do to
> install guile 1.8.1 as /usr/bin/guile-1.8.1 and guile 1.8.2 as
> /usr/bin/guile-1.8.2"

Install under different $prefix.

> Where configure.ac/Makefile.am
> should put libmysuperextension.la (+ .so, etc) file ?

Under the $prefix of the version you're building against.

It's that simple.  There's nothing more to say.  When guile works your
extension works.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Managing Guile and extensions versions

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> The two developers who have thought most on this subject in the past
> are Marius (Vollmer) and Rob (Browning), and they've both been out of
> circulation for the last week or so.  No doubt one of them will
> respond when they catch up with the list.

I just noticed this thread, though I haven't read it yet.  For better
or for worse, I've been busy enough recently that I haven't been
watching guile-user very closely.  (I *have* been paying some
attention to guile-devel.)

With respect to this issue, I may well have some comments, but it
might also be a bit before I can read carefully, try and remember the
issues involved, and then come up with something useful to say.

Also, with the exception of high priority issues (and please let me
know if there are any), my primary focus for now will be the 1.6.8
release.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user