From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel Subject: Re: summer of code project: cpan Date: Tue, 29 Mar 2011 01:46:35 +0200 Message-ID: <874o6mn6zo.fsf@gmx.at> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1301356021 27861 80.91.229.12 (28 Mar 2011 23:47:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2011 23:47:01 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 29 01:46:56 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4M99-0002VO-7O for guile-devel@m.gmane.org; Tue, 29 Mar 2011 01:46:55 +0200 Original-Received: from localhost ([127.0.0.1]:53156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4M98-00074s-LO for guile-devel@m.gmane.org; Mon, 28 Mar 2011 19:46:54 -0400 Original-Received: from [140.186.70.92] (port=53979 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4M90-00074a-1k for guile-devel@gnu.org; Mon, 28 Mar 2011 19:46:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4M8y-0005Ig-I4 for guile-devel@gnu.org; Mon, 28 Mar 2011 19:46:45 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:35647) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Q4M8y-0005IU-6q for guile-devel@gnu.org; Mon, 28 Mar 2011 19:46:44 -0400 Original-Received: (qmail invoked by alias); 28 Mar 2011 23:46:41 -0000 Original-Received: from 83-215-154-5.hage.dyn.salzburg-online.at (EHLO nathot.lan) [83.215.154.5] by mail.gmx.net (mp068) with SMTP; 29 Mar 2011 01:46:41 +0200 X-Authenticated: #3102804 X-Provags-ID: V01U2FsdGVkX19s86ou9INsJ8tteJYwDIj/P4Gi8cLUkJOaGoC7hm Bzj/DppsYSleKg Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by nathot.lan (Postfix) with ESMTP id BECDC3A68F; Tue, 29 Mar 2011 01:46:40 +0200 (CEST) Original-Received: from nathot.lan ([127.0.0.1]) by localhost (nathot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RqdbGaN18hH; Tue, 29 Mar 2011 01:46:35 +0200 (CEST) Original-Received: from delenn.lan (delenn.lan [192.168.3.11]) by nathot.lan (Postfix) with ESMTP id 8C5283A685; Tue, 29 Mar 2011 01:46:35 +0200 (CEST) Original-Received: by delenn.lan (Postfix, from userid 1000) id 419F12C00C1; Tue, 29 Mar 2011 01:46:35 +0200 (CEST) In-Reply-To: (Andy Wingo's message of "Sat, 19 Mar 2011 12:45:14 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.22 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:12036 Archived-At: Andy Wingo writes: > Hello all, > > Now that GNU is in the Google SoC, I'd like to propose again a CPAN for > Guile. (It does needs a proper name, but that name doesn't have to > correspond to the name of the command-line utility; see my other mail > about "guido".) > > The proposal would be to start from dorodango, and to use stowfs > locally. We keep (largely) the dorodango network interfaces, but the > implementation exists in a Guile-specific project, with a non-dorodango > name (so as not to conflict with Andreas's more portable project). > Well, I believe Dorodango is quite modular, and large parts could be re-used as-is. Obviously, I'd like to avoid a "real" fork of the codebase -- ideally code should be able to flow easily between Dorodango and its Guile-specific cousin in both directions. I am also open to reconsider design decisions, should some of them not make sense for Guile. > Locally it uses something like stowfs and $XDG_DATA_DIRS, as noted in > the previous SoC thread. > Support for the XDG Base Directory Specification would indeed be welcome in Dorodango. Also, I am actually quite fond of how GNU Stow works; adding support for that as an additional mode of operation would be nice mini-project. > The project can be developed outside of Guile initially, just > integrating by defining "guido" commands. If everything works it can be > integrated within Guile itself. > One thing that speaks against directly reusing the dorodango codebase (and later moving parts of it into Guile core) is that it comes with some dependencies (from Dorodango's own package metadata): (srfi) ; Not relevant on Guile, it provides the required SRFIs in core (wak-foof-loop) ; Used all over the place (wak-fmt) ; Ditto (wak-irregex) ; Used in a few places; SRE syntax is exposed to the ; user, however (wak-parscheme) ; Used in only one place (minor UI code) (spells) ; That one's really prevasive: pathnames, filesystem, ; logging, ... (industria) ; Only used for handling ZIP, which is quite slow on ; Guile anyway. (ocelotl) ; Weight-balanced trees, HTTP client, URIs. > Andreas, what do you think about this? If you are happy with this I > would be most pleased to have you as a co-mentor. > I'd certainly be willing to answer all kinds of questions on the Dorodango codebase and give advice as good as I can, regardless of what direction the project takes. I have a few ideas that would help bringing the codebase of Dorodango "closer to Guile": - Work on an SRE frontend to Guile's regexp engine. I believe there might be some code out there doing that already (Guile-SCSH?). - Introduce a Stow-like mode of operation. This should be possible without abandoning the current ZIP support, and would allow for: - Using non-random-access archive files (e.g. tar.xz). - Using external programs to (completely) unpack a bundle, eliminating the current performance issue introduced by Guile's relatively slow number-crunching. - Eliminate the (hard) dependency on Industria. So what remains as (quite) hard dependencies would be: foof-loop, fmt, and spells; the others should not be too hard to eliminate in some way or the other. WDYT? Regards, Rotty -- Andreas Rottmann --