From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117248 invoked by alias); 31 Oct 2016 22:11:50 -0000 Mailing-List: contact kawa-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: kawa-owner@sourceware.org Received: (qmail 117236 invoked by uid 89); 31 Oct 2016 22:11:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:1244, drawing, picture X-HELO: homiemail-a22.g.dreamhost.com Received: from sub3.mail.dreamhost.com (HELO homiemail-a22.g.dreamhost.com) (69.163.253.7) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 31 Oct 2016 22:11:39 +0000 Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id B66B311406A; Mon, 31 Oct 2016 15:11:37 -0700 (PDT) Received: from vereq.eip10.org (cpe-74-75-122-130.maine.res.rr.com [74.75.122.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: chaw@eip10.org) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 97430114067; Mon, 31 Oct 2016 15:11:37 -0700 (PDT) Received: from chaw by vereq.eip10.org with local (Exim 4.84_2) (envelope-from ) id 1c1Kno-0000cI-Ek; Mon, 31 Oct 2016 18:11:36 -0400 To: Per Bothner cc: kawa Subject: Re: (kawa pictures) square-limit pictures From: "Sudarshan S Chawathe" Reply-To: "Sudarshan S Chawathe" In-reply-to: Your message of "Sun, 30 Oct 2016 12:10:28 -0700." <07c5b6ff-e52b-7869-6761-29138d840456@bothner.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2372.1477951896.1@vereq.eip10.org> Date: Mon, 31 Oct 2016 22:11:00 -0000 Message-ID: <2373.1477951896@vereq.eip10.org> X-IsSubscribed: yes X-SW-Source: 2016-q4/txt/msg00046.txt.bz2 > I've considered adding a procedure to help bridge the SICP > model and the Kawa model. Something like: > > (transform-to RECT PICTURE) > > This would be equivalent to some (with-transform TRANSFORM PICTURE) > such that the bounds of the result matches RECT. This procedure would be nice to have. > More generally RECT could be a parallelogram. (Note a rotated rectangle is > a parallelogram but is not considered a rectangle.) In that case the > bounds of the transform would not match RECT, but would have the > same bounds as RECT. > > The RECT corresponds to the "frame" of SICP. On a related note, regarding Racket's sicp-pict package you noted earlier: Based on a quick look at the source code, it seems to use a bitmapped drawing canvas as the basis for segments->picture from SICP, with the other SICP procedures being mostly verbatim (with some flipped names, such as frame-edge1 instead of edge1-frame, I assume to conform to current Scheme naming conventions). I'm thinking of writing something similar with Kawa. Actually I have a lot of it done, but I'm working on how best to hook things into the Kawa graphics interface. (The way I did it earlier was a bad hack.) Regards, -chaw