Re: the future of Guile

[Daniel Ridge <dskr@mac.com>]

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 <spk121@yahoo.com> 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 <roland.orre@neurologic.se>
>
>> 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