From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: `guile-debugging' feature requests Date: Mon, 26 Jun 2006 14:19:51 +0200 Organization: LAAS-CNRS Message-ID: <87psgwaz2w.fsf@laas.fr> References: <873be1o9uw.fsf@laas.fr> <87fyhwf173.fsf@ossau.uklinux.net> 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 1151324420 6704 80.91.229.2 (26 Jun 2006 12:20:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 26 Jun 2006 12:20:20 +0000 (UTC) Cc: Guile-Devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 26 14:20:15 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fuq4X-0007VN-Rn for guile-devel@m.gmane.org; Mon, 26 Jun 2006 14:20:10 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fuq4X-0005nW-7Y for guile-devel@m.gmane.org; Mon, 26 Jun 2006 08:20:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fuq4S-0005nH-CZ for guile-devel@gnu.org; Mon, 26 Jun 2006 08:20:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fuq4P-0005n5-P5 for guile-devel@gnu.org; Mon, 26 Jun 2006 08:20:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fuq4P-0005n2-LO for guile-devel@gnu.org; Mon, 26 Jun 2006 08:20:01 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FuqGH-00082u-Hu for guile-devel@gnu.org; Mon, 26 Jun 2006 08:32:17 -0400 Original-Received: by laas.laas.fr (8.13.7/8.13.4) with SMTP id k5QCJrU7006408; Mon, 26 Jun 2006 14:19:59 +0200 (CEST) Original-To: Neil Jerram X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 8 Messidor an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Neil Jerram , Guile-Devel In-Reply-To: <87fyhwf173.fsf@ossau.uklinux.net> (Neil Jerram's message of "Fri, 23 Jun 2006 14:31:28 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS X-MIME-Autoconverted: from 8bit to quoted-printable by laas.laas.fr id k5QCJrU7006408 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5993 Archived-At: Hi, Neil Jerram writes: > ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > >> * Completion >> >> Currently, `gds-complete-symbol' only completes symbols based on those >> defined in the current module of the attached Guile process. This is >> fine, but it would be nice if a completion function compatible with >> `hippie-expand' was provided, so that one can plug it in the middle of >> other completion functions. > > I don't yet know what this means in detail, because I've never looked > at how hippie works. I'll take a look soonish, but if you happened to > work it out for me first I shouldn't mind! I'm not an Emacs expert, so I'm afraid I won't be able to provide you with the exact patch needed to make it work. ;-) `hippie-expand' works by calling the functions listed in `hippie-expand-try-functions-list' which is documented as follows: The list of expansion functions tried in order by `hippie-expand'. To change the behavior of `hippie-expand', remove, change the order of, or insert functions in this list. These should be one-argument functions that are passed a previous completion result. Hippie provides a number of such functions out of the box: `try-complete-file-name', `try-complete-lisp-symbol', etc. Unfortunately, from a quick look at `hippie-exp.el', it seems that these functions pass their result by mutating `he-expand-list' which is not exported. Thus, in order to implement hippie-compatible completion functions, either hippie-expand has to be adapted, or your own completion function has to be made part of hippie-expand (which it not possible in your case). :-( >> * Module Unloading/Reloading >> >> When one is writing code and periodically testing it via GDS, it may >> sometimes be useful to tell GDS to entirely unload/reload a given >> module. This would be particularly helpful when testing features that >> span several modules. I don't know exactly what would be feasible in >> this area, and this would certainly require support from Guile itself. >> >> Also, I don't know what other Scheme/Lisp development environments all= ow >> for in this respect. Does that sound like a useful usage pattern? > > I completely agree as regards reloading, and I'm sure from my own > experience that it is a frequently useful usage pattern. > > The implementation is just "load the relevant file", I believe; the > only slightly tricky part is working out the most convenient possible > interface. > > I'm not sure about unloading. I don't recall ever wanting to do it in > practice, and I'm not sure Guile has any way of achieving it. Unloading would allow the modules' name spaces to be cleaned up before one reloads it, thus potentially avoiding mysterious side-effects. I believe module unloading could be achieved either by restarting a Guile process or by "undefining" the module that is to be reloaded before reloading it: (nested-remove! the-root-module '(%app modules foo bar)) However, the name space of the module users would need to be updated as well. One possibility would be to keep a list of all existing modules (this can be done by "overloading" `make-module'). Another one would be to include as an object property of each module object the list of its users (perhaps by overloading `module-use!'). Upon reloading of a module, the `module-uses' list of its users would be traversed in order to remove the relevant interface and replace it with a new one obtained via `resolve-interface' (note: you need to know the options that must be provided to `resolve-interface' here). In either case, you'd then have to play with the innards of the module system which can be quite tricky. I played a bit in the REPL with the above and was unable to reload a module after I had removed it... I'm afraid these thoughts won't be very helpful. ;-) Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel