From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.user Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Wed, 24 Apr 2002 22:32:03 -0700 Sender: guile-user-admin@gnu.org Message-ID: References: <87ads6nf1v.fsf@zagadka.ping.de> <87it6s7sjz.fsf@alice.rhinosaur.lan> <87662hkvya.fsf@raven.i.defaultvalue.org> <873cxkj54j.fsf@raven.i.defaultvalue.org> Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1019713195 17458 127.0.0.1 (25 Apr 2002 05:39:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 25 Apr 2002 05:39:55 +0000 (UTC) Cc: a.rottmann@gmx.at, mvo@zagadka.ping.de, neil@ossau.uklinux.net, guile-devel@gnu.org, 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 170bz0-0004XT-00 for ; Thu, 25 Apr 2002 07:39:54 +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 170byF-00023j-00; Thu, 25 Apr 2002 01:39:07 -0400 Original-Received: from ca-crlsbd-u5-c4a-a-172.crlsca.adelphia.net ([24.48.214.172] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170bvk-00021c-00; Thu, 25 Apr 2002 01:36:32 -0400 Original-Received: from ttn by giblet with local (Exim 3.33 #1 (Debian)) id 170brP-0000Gx-00; Wed, 24 Apr 2002 22:32:03 -0700 Original-To: rlb@defaultvalue.org In-Reply-To: <873cxkj54j.fsf@raven.i.defaultvalue.org> (message from Rob Browning on Wed, 24 Apr 2002 13:58:20 -0500) 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:304 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:304 From: Rob Browning Date: Wed, 24 Apr 2002 13:58:20 -0500 For the time being, I think I had better respond to you on technical points if I think I can help, and limit my communications otherwise. The "Have you stopped beating your wife lately?" communication strategy just makes me tired. It makes work that would otherwise be enjoyable more of a chore. OPMMV. fair enough. technically, there are several plug-in architectures in existence to study from. internal interfaces documentation is available for some of them (typically, the good ones :-). our job as a community of guile programmers is to know guile well enough (including through using guile) to be able to precisely describe our guile usage patterns wrt other objects on the system. these patterns most likely would be influenced (in practice) by usage of these existing plug-in implementations. next, those who factor break down the patterns into attributes of the general usage. attributes may map to variables and procedures, which are slammed into source by those who code, and explained thoroughly by those who write about code. this code and documentation is the toolkit and mini-language for expressing an FFI. it could be delivered alone as an "extensible attribute mapping framework" or whatever. interesting FFIs (ltdl, bfd, *.out, network streams, source in some vfs, loopback dev, etc) can be expressed using this toolkit and (here's the slackful part for maintainers :-) experimentation at that level is a user concern and can be done completely in user land. no worries, oop ack! for the purposes of bundled object libraries (aside from libguile), guile itself uses the FFI api, in 1.4 or 1.6 or 1.8 or ... fashion, or perhaps in the fashion of one of the users' creations. so, this is what needs to be done to really put the active design phase back in the users' hands and leave the maintainers w/ the core to tend, for FFI. bonus: this kind of process can run parallel w/ maintainers' own experimentation w/ FFI architectures, which upon reflection, cannot be called stupid because experimentation is a path w/ unknown ending (the only stupidity would be not seeing this ;-). to kick this off, can someone post an exhaustive summary of plug-in architectures? i will add that (and any further additions) under workbook/ somewhere, no questions asked. some seed attributes to think about: is-2-phase has-hook is-hooks-based depends-on-env-vars passes-through-env-vars-prefixing passes-through-env-vars-modifying-in-some-weird-way unloadable requires-system part-of-ABSTRACTION-PROGRAM-feature-list [your attributes here] coders feel free to post code (if you know what you're doing :-). everyone elese, please ask questions and point out flaws in the approach. i think we can get this ffi-toolkit api prepared and in use for 1.8. thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user