From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Kraft Newsgroups: gmane.lisp.guile.devel Subject: Re: Updated Guile Tutorial Date: Thu, 13 Aug 2009 09:43:10 +0200 Message-ID: <4A83C40E.3010206@domob.eu> References: <4A7B223E.6050501@domob.eu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250149381 665 80.91.229.12 (13 Aug 2009 07:43:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Aug 2009 07:43:01 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Aug 13 09:42:54 2009 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.50) id 1MbUxY-0004rw-IO for guile-devel@m.gmane.org; Thu, 13 Aug 2009 09:42:52 +0200 Original-Received: from localhost ([127.0.0.1]:53169 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbUxV-0001Eh-Tq for guile-devel@m.gmane.org; Thu, 13 Aug 2009 03:42:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MbUxT-0001Ec-2T for guile-devel@gnu.org; Thu, 13 Aug 2009 03:42:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MbUxO-0001EQ-13 for guile-devel@gnu.org; Thu, 13 Aug 2009 03:42:46 -0400 Original-Received: from [199.232.76.173] (port=41175 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MbUxN-0001EN-Tc for guile-devel@gnu.org; Thu, 13 Aug 2009 03:42:41 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:14604) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MbUxN-0007AB-BP for guile-devel@gnu.org; Thu, 13 Aug 2009 03:42:41 -0400 Original-Received: from tatiana.utanet.at ([213.90.36.46]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MbUxK-0006f8-Sf for guile-devel@gnu.org; Thu, 13 Aug 2009 03:42:39 -0400 Original-Received: from pam.xoc.tele2net.at ([213.90.36.6]) by tatiana.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MbUxB-0008FY-FO; Thu, 13 Aug 2009 09:42:29 +0200 Original-Received: from d86-33-51-52.cust.tele2.at ([86.33.51.52] helo=[192.168.1.18]) by pam.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MbUxB-0004lq-9q; Thu, 13 Aug 2009 09:42:29 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:9097 Archived-At: Hi Andy, thanks for your comments and checking over my revised tutorial! Andy Wingo wrote: > A few comments, IMO of course. Neil probably has a better perspective. I agree with you in general on those, and will try what I can improve on them; so please wait with a commit in any case ;) Should I think that the current version is best of all my trials, I'll also let you know... > 1) It would be better to have a more neutral narrator -- not a > first-person narrator. If you feel like you need to speak from the > first person, use "we". OTOH your style is infectious :), so perhaps > it would work as "Guile Tutorial, by Daniel Kraft" :) That's something I usually also try to achieve in writings "like that" -- however, I liked the original's style and tried to get my own version in the same spirit. Here, I'm not sure if I can get rid of first person entirely; and I think I tried to use "we" wherever possible, but for stuff like "I wanted to use Gtk+ but resided finally to Gnuplot because..." I'm not sure how to do this; overall, it's really meant from the author's perspective and not something like "we're going to do that now". I'll still try to work over the text when I find time and maybe I can reformulate it -- concrete suggestions are welcome, if you stumble upon certain passages, of course. > 2) Don't mention the history of the tutorial. Just have it be a current > document. I wanted to give credits to the original author, but you're right that I should probably move this to some concluding section. As you make me think about that, I also need to add a GNU FDL note somewhere. > 3) In general, use short sentences. Let your words breathe. Ok, I'll see what can be done there; I just fear that this is a remainder of German being my native language, so I'm usually not content with short sentences... > 4) If you're forking to run gnuplot, why not do so from Scheme? Of > course if you did that it would obviate the whole "extending C" > story, but still, if given this particular problem, that's what I'd > do. I've never tried this actually myself, but I think it would not be too hard to implement all of this in Scheme alone; but as you mentioned, I just needed something to write in C ;) But if you've got a suggestion as what I could reasonable still change (maybe some final remarks that this example would also be possible in Scheme) I'll consider it. > 5) Running a main loop (as gtk+ does) and a REPL is indeed an > interesting problem. See event-repl.scm or graphical-repl.scm in > guile-gnome for a couple of takes. I imagine the "correct" solution would be to start the REPL in a seperate thread and do drawing by updating some shared data structure that is read and rendered from the Gtk+ loop's exposed-callbacks; or something alike. This shouldn't be too hard if we wanted to implement a clean program anyways, but for means of the tutorial I think the current version is better. > 6) I wish we had a better Scheme->C story; our C->Scheme story is fine, > but a better FFI would be nice. I'm not sure about that... For all I did so far, the Scheme->C stuff I regard also as quite good. The only thing is that you need to write wrappers for each function; so maybe we could try to get a FFI where you can just define the interface of a C function and Guile does the SCM boxing/unboxing accordingly on calls. Are there already plans (or at least the concrete desire) to do stuff like this? I think at least for some very basic functionality it should not be too hard to do? Cheers, Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri