On mike's question about the natural analog of the jar file, I find
that one of the big binary distribution hurdles for guile code has
been static paths baked everywhere. Static, absolute paths get baked
into libtool .la files when the underlying platform does not
necessarily require it.
Guile itself contributes to this relocatability problem with the way
guile-config uses %guile-build-info,%library-dir,%package-data-dir,%
site-dir.
I use guile as an extension language in all of my codes. In almost
every case I need to build guile alongside my application. Guile's
relocatability problems become my own. I hack boot-9.scm to prefer a
prefix from the environment to the one baked into % guile-build-info.
My programs are typically wrapped with a shell script that figures out
where they live and updates LD_LIBRARY_PATH and the prefix for guile
and execs the prog.
When I use guile to load shared objects, I'm not demonstrating a
preference for Scheme hacking vs extension hacking, as some would
claim. Instead, I'm using it as as as 'extension linker' that grabs
code needed by my underlying application. Guile often just marshalls
args from C through Scheme back to C. Along the way, many calls become
transparent RPCs. Guile is absolutely excellent at this. In many
cases, I use guile to marshall args to RPCs evaluated in other Scheme
runtimes that play less well with C.
With the elimination of just a couple of these problems, guile and
guile extended apps run quite nicely from live CDs, loopback mounted
disk images, and even Apple's relocatable application bundles.
On Dec 5, 2007, at 10:40, Mike Gran <[EMAIL PROTECTED]> wrote:
On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:
Pre-answer to all: the most important thing is to make clear
what are the priorities. With a "language for extensions"
(LFE) there are certain priorities, with a "Scheme
implementation" (SI) there are others. I fear that if no
choice is made Guile will be wiped out by other Schemes.
As far as being an LFE, 1.8.x has been a big improvement over 1.6.
The API is much cleaner when wrapping stuff by hand.
From: Roland Orre <[EMAIL PROTECTED]>
Today, however, I find that there are nearly no extension
libraries available for guile. As a shell scripting language
I prefer python because it has a very simple and clean
shell interface. To extend my applications beyond real number
crunching with e.g. graphical interphases (currently working
with xlib...) I feel a limitation and have more and more often
looked upon python where a lot of libraries are available for
GUI, database and you name it.
One problem here is that there does need to be a richer library
that is official and downloadable right from
www.gnu.org/software/guile. Unit test, documentation,
cgi, http, sql, md5, utf8, xml, and perhaps pickle.
Much has been done (GEE, Guile-lib, guile-gtk, all of TTN),
but, each has its own packaging scheme, documentation
scheme. None of them are released in a coordinated manner
with the Guile releases themselves.
This goes back to the packaging problem. After I've written a
program,
I'd like to give it away for others to use. Giving code away in a
scripting
language should be easy. It isn't easy here.
First, dependencies on the many libraries are
difficult to coordinate.
Second, most non-trivial scripts require the whole of the configure,
make, make install, LD_LIBRARY_PATH, %load-path overhead.
Where is the analog of a Java jar file?
Apologies if my rant has drifted off topic.
Thanks,
Mike Gran
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
