From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vorfeed Canal Newsgroups: gmane.lisp.guile.user Subject: Re: PHP to GUILE Date: Tue, 27 Sep 2005 13:20:42 +0400 Message-ID: <6efab2350509270220af797d8@mail.gmail.com> References: <6efab235050925145055ba774c@mail.gmail.com> <873bnrlix6.fsf@ossau.uklinux.net> <6efab235050926131843ce69e2@mail.gmail.com> <6efab2350509261318537b55a4@mail.gmail.com> <87u0g7tpwt.fsf@zip.com.au> Reply-To: Vorfeed Canal NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1127814783 32023 80.91.229.2 (27 Sep 2005 09:53:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2005 09:53:03 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 27 11:52:59 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKC7i-0000hN-OL for guile-user@m.gmane.org; Tue, 27 Sep 2005 11:51:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKC7i-0002T6-7v for guile-user@m.gmane.org; Tue, 27 Sep 2005 05:51:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKBwK-0004Qv-9J for guile-user@gnu.org; Tue, 27 Sep 2005 05:39:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKBwJ-0004Qb-CM for guile-user@gnu.org; Tue, 27 Sep 2005 05:39:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKBuf-00041v-PU for guile-user@gnu.org; Tue, 27 Sep 2005 05:38:15 -0400 Original-Received: from [72.14.204.201] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EKBdj-0007Vm-1p for guile-user@gnu.org; Tue, 27 Sep 2005 05:20:43 -0400 Original-Received: by qproxy.gmail.com with SMTP id e12so539825qbe for ; Tue, 27 Sep 2005 02:20:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gPdQz2KGG+QOT6XEqZaoouEVO8vJ3LOp+w8YIAMX/iSyFrzq+Lr7oIcM5uPZe8Z0NGELkqqZrIKbwTozzSDU8dn11QiS7k6ArOHresMUUS08MHHIv79K5WJa8v4v7FC6zltcRp1h9EutKzGrfpx5KoLE9OEElkR7KAGq2Y2T+Mg= Original-Received: by 10.65.116.20 with SMTP id t20mr637609qbm; Tue, 27 Sep 2005 02:20:42 -0700 (PDT) Original-Received: by 10.65.100.16 with HTTP; Tue, 27 Sep 2005 02:20:42 -0700 (PDT) Original-To: guile-user@gnu.org In-Reply-To: <87u0g7tpwt.fsf@zip.com.au> Content-Disposition: inline X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4785 Archived-At: On 9/27/05, Kevin Ryde wrote: > Vorfeed Canal 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