From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.user Subject: Re: SLAYER announcement and help request for preparing a GNU package Date: Wed, 08 May 2013 11:34:12 +0200 Message-ID: <87wqr9n7cb.fsf@zigzag.favinet> References: <874nefpzq0.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1368005574 27975 80.91.229.3 (8 May 2013 09:32:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 May 2013 09:32:54 +0000 (UTC) Cc: "guile-user@gnu.org" To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed May 08 11:32:53 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ua0k0-0004Wg-J2 for guile-user@m.gmane.org; Wed, 08 May 2013 11:32:52 +0200 Original-Received: from localhost ([::1]:46822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ua0jz-0007XW-Pe for guile-user@m.gmane.org; Wed, 08 May 2013 05:32:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ua0jM-0006sW-F4 for guile-user@gnu.org; Wed, 08 May 2013 05:32:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ua0jI-0001sl-CE for guile-user@gnu.org; Wed, 08 May 2013 05:32:12 -0400 Original-Received: from smtp205.alice.it ([82.57.200.101]:55539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ua0jI-0001sX-29 for guile-user@gnu.org; Wed, 08 May 2013 05:32:08 -0400 Original-Received: from zigzag.favinet (79.41.72.189) by smtp205.alice.it (8.6.060.15) id 511D10740D2BC470; Wed, 8 May 2013 11:31:56 +0200 Original-Received: from ttn by zigzag.favinet with local (Exim 4.72) (envelope-from ) id 1Ua0lV-0002ie-BW; Wed, 08 May 2013 11:34:25 +0200 In-Reply-To: (Panicz Maciej Godek's message of "Wed, 8 May 2013 00:50:32 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.101 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10339 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable () Panicz Maciej Godek () Wed, 8 May 2013 00:50:32 +0200 both guile-sdl and guile-figl copy the scm modules to $(prefix)/share/guile/site..., but apparently they both do that in a different way (which means there's no standard way), and none of them allows to 'fine tune' that directory with an optarg to ./configure I like how guile-ncurses does it. Maybe Guile-BAUX (and SNUGGLE[0], which i forgot to mention previously) will follow its lead. And the whole thing makes me wonder about the status of guile documentation. Back in time, Guile inherited the documentation maintenance mindset of Emacs, i.e., "docstrings are for interactive (repl) consumption, full descriptions belong in the manual". This makes for a lot of work, which Emacs can easily demand of its large hacker population, but Guile cannot (its hackers being relatively few and somewhat prone to solipsism). So naturally, as w/ any situation where todo exceeds doers, some stuff does not get done or gets done w/ less attention than deserved. At present, there is a protocol between the repl and the database of docstrings (guile-procedures.txt) only, and only for libguile(?). And those laboriously maintained docstrings do not make it into the manual, either, by dint of the mindset. If that were to change, i think it would be a SMOP to arrange to significantly improve the status of Guile documentation. (Maybe that has already happened, but i missed it?) Personally, i think the ideal model is to define a protocol between the repl and the manual-viewing program, such that full documentation is the only thing that needs to be maintained. IMHO, the best layout for that is intro, concept and expository text in .texi, and proc/var/etc details in .h/.c/.scm comments. That's what Guile-BAUX supports, no surpise. The guide is really great (although sometimes it remains silent about certain features that can be found in header files), but I've observed that doc-strings for built-in functions are no longer available, even though they are specified. Could you give some examples? And besides, how do the aforementioned modules (those are, as I reckon, tsar and c-tsar) refer to guile-snarf-docs that is shipped with guile source? They don't. The script guile-snarf-docs is not installed, and thus not available to third parties (like SLAYER or Guile-SDL). But even if it were, its method has changed over the years; it might give bad results if used w/ a different Guile version than its original distribution. Believe me, i [pw]ondered the same thing. That's what led to Guile 1.4.x hacking and doc fu[1], and eventually, Guile-BAUX (and SNUGGLE). ___________________________________________________ [0] http://www.gnuvola.org/software/snuggle/ [1] http://www.gnuvola.org/software/guile/ http://www.gnuvola.org/software/guile/doc/Doc-Maintenance.html =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlGKHBgACgkQZwMiJEyAdQIElACfbqVr1UKwhf7NUegeTrwWZmmk qBgAoKV7mTIwojx8NP0AEeYb9+27f6yY =vSmL -----END PGP SIGNATURE----- --=-=-=--