Re: PHP to GUILE

[Vorfeed Canal]

On 9/27/05, Kevin Ryde <address@hidden> wrote:
> Vorfeed Canal <address@hidden> 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).