From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: language translator help Date: 16 May 2002 23:57:54 +0200 Sender: guile-user-admin@gnu.org Message-ID: <87znyzhi1p.fsf@zagadka.ping.de> References: <15561.38014.967466.255795@segfault.bogus.domain> <15563.18078.788420.299836@segfault.bogus.domain> <87ofg4zkhp.fsf@becket.becket.net> <87d6vxp265.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1021586473 28999 127.0.0.1 (16 May 2002 22:01:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 16 May 2002 22:01:13 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 178TJB-0007Xc-00 for ; Fri, 17 May 2002 00:01:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 178TId-00022F-00; Thu, 16 May 2002 18:00:39 -0400 Original-Received: from dialin.speedway42.dip67.dokom.de ([195.138.42.67] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 178TG0-0001si-00 for ; Thu, 16 May 2002 17:57:57 -0400 Original-Received: (qmail 1080 invoked by uid 1000); 16 May 2002 21:57:54 -0000 Original-To: ttn@glug.org In-Reply-To: Original-Lines: 153 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:445 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:445 Thien-Thi Nguyen writes: > From: Marius Vollmer > Date: 15 May 2002 22:49:06 +0200 > > Please don't do this in the context of 1.4 releases. We have the 1.7 > series for experiments like that. Please keep the 1.4 releases > (if you feel that you must divert resources to them) as bug fixing > releases. > > who uses libguilereadline independent of using libguile? who uses > libqthreads independent of using libguile? moving these things inside > is a bugfix; the user experience is not changed incompatibly. What is the bug? The point is not to allow linking to libguilereadline without also linking to libguile. We want to support linking to libguilereadline and to the other extension libraries together with libguile using the ld linker. I don't know nearly as much about shared libraries as the libtool guys do, but I do know that treating them right is far from trivial. So my position is that without good reasons we should keep our shared libraries things as simple as possible and deviate as little from the usual way of handling shared libraries as possible. Unix shared libraries are in a flat namespace with versioning, cobbled together via some environment variables. I don't like this design either, but putting our extension libraries into this namespace poses no problems (that I could see). We can't use the versioning from 'dynamic-link' yet, and that is a problem, but we should ideally fix this by making the versioning available to all users of lt_dlopen, not by working around it via implementing our own versioning on top of the existing one (by putting shared libraries outside their natural namespace). The hack for 1.6 to include the versioning information explicitely in the filename is such a workaround, and will hopefully be very temporary. > overall maintenance is eased. (all 1.4.x releases aim for this -- > sorry, i was not clear about that goal.) I don't think we should have an extended 1.4.x series. If anything, the fixes should be backported from the HEAD branch. But I haven't heard enough convincing arguments for continuing the 1.4.x release series, yet. > On the specific point of what exactly a Guile extension or plugin is, > where to install it, how to link to it, etc, I remain convinced that > Guile itself should continue to treat its extensions as standard > operating system shared libraries, using libtool as the interface to > the operating system. > > of course you do (because you don't take user feedback into account on > this issue perhaps), I like to think I do. > and because of this, no third party can produce guile plug-ins > cleanly w/o major hassle, The "Guile plug-in" is just a shared library. Where is the major hassle in producing it? > Experimentation can occur outside of Guile. Packages that need to go > beyond the simplistic shared library view of the core Guile and want > to impose additional rules on the use of their shared libraries can do > so to a very large degree without needing any cooperation from Guile > itself. > > you don't get it. packages WANT cooperation from guile (otherwise guile > is seen as un-cooperative and a PITA to work with -- duh!). Yes, they want cooperation and the are entitled to it, of course. I said "experimentation". Package developers that are dissatisfied with Guile's approach can try to do better without cooperation from Guile. Being able to proceed without needing explicit cooperation from Guile is a feature. Not needing to proceed on ones own because there already just the right cooperation from Guile is even better, of course. I'm not saying that the last word on the extension/plugin issue has been said. The first thing I ask you to is to not engage in private, isolated experiments in the 1.4.x series. Maybe I have misunderstood your intentions. > i can harp on this more, but because you don't take user feedback > into account on this issue, what's the point? As I said, I think I do take feedback into account (from users _and_ developers ;). That's how I arrived at the position that I'm currently taking. > Negative. I don't have the feeling that we are dangerously > incompatible in the 1.6 series. What do others think? It would be > bad to switch strategies at this point, even if you have a point. > > if you can articulate your strategy in the first place, that would be a > good start for discussion. if you can record this, that would be best. The strategy that I was talking about is to release 1.6 from the 'stable' branch in th immediate future. Maybe strategy is the wrong word for this. > What is wrong with Guile's current approach other than that you don't > like it? > > guile has a bunch of people working on it for their own ego fulfillment > (self-included), w/ varying levels of organization and maturity. this > is not to like or dislike but to understand and work through. I meant Guile's specific approach towards the extension/plugin issue. > What? The split is there so that people can choose not to be > bothered with developers chit chat. You don't need a license to > subscribe to guile-devel. It's a tool of organization, you process > junkie, not of dividing and conquering people. > > it's a tool of insulation, and fosters this kind of dialogue: > > developer-1: hey, what do you think of BRAINDEAD-IDEA? > developer-2: THOUGHTLESS-AFFIRMATION. > user-1: i don't understand. > developer-1 and developer-2: don't worry, we are the experts; > you'll love it, really! > > [6mo later] > developer-1: well, we have to start over again. > developer-2: THOUGHTLESS-AFFIRMATION. > user-2: hey, that breaks my code. > developer-1 and developer-2: you're a user, go away! Is that really how things typically are? And they would stop with just one mailing list? I don't think so, on both points. > all guile users are programmers; (but not developers of guile itself) > if you can't see how guile developers have something in common w/ > guile users Of course they have. We have two _mailing lists_, not two strictly divided groups of people. We must be talking past each other here. Anyway, you can't really have write privs and be unsubscribed from guile-devel at the same time. So even if you protest the existence of guile-devel, do it by not posting to it instead of ignoring it completely. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user