From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56987 invoked by alias); 18 Feb 2016 19:59:40 -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 56946 invoked by uid 89); 18 Feb 2016 19:59:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*r:sk:zimbra., H*RU:sk:zimbra., Hx-spam-relays-external:sk:zimbra., H*UA:Win X-HELO: m.nuecho.com Received: from m.nuecho.com (HELO m.nuecho.com) (64.187.188.7) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 18 Feb 2016 19:59:31 +0000 Received: from localhost (localhost [127.0.0.1]) by m.nuecho.com (Postfix) with ESMTP id 2ADE47C1983; Thu, 18 Feb 2016 14:59:23 -0500 (EST) Received: from m.nuecho.com ([127.0.0.1]) by localhost (zimbra.nuecho.ad [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rqvmJBUkAPBt; Thu, 18 Feb 2016 14:59:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by m.nuecho.com (Postfix) with ESMTP id 5D1AD7C1B67; Thu, 18 Feb 2016 14:59:22 -0500 (EST) Received: from m.nuecho.com ([127.0.0.1]) by localhost (zimbra.nuecho.ad [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g1soavGCd6rd; Thu, 18 Feb 2016 14:59:22 -0500 (EST) Received: from zimbra.nuecho.ad (zimbra.nuecho.ad [192.168.157.42]) by m.nuecho.com (Postfix) with ESMTP id 3C0067C1983; Thu, 18 Feb 2016 14:59:22 -0500 (EST) Date: Thu, 18 Feb 2016 19:59:00 -0000 From: Dominique Boucher Reply-To: Dominique Boucher To: Per Bothner Cc: "Rafik Naccache [TNTeam]" , kawa@sourceware.org Message-ID: <456652732.135358.1455825562148.JavaMail.zimbra@nuecho.com> In-Reply-To: <56C61423.4070801@bothner.com> References: <56C5EED0.8030500@tnteam.rocks> <56C61423.4070801@bothner.com> Subject: Re: What is the Development Environment of Choice for Kawa? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q1/txt/msg00020.txt.bz2 Hello, I'm the author of SchemeScript. Per is right. It's not actively maintained, although it's still occasionally used here at Nu Echo. The embedded Kawa is a pretty old version (7 years old!). If there is enough interest, I could try to upgrade it. But I'm sure there will be some syntactic/lexical elements of Kawa that will not be supported. And I can't commit to fixing those in the very short term. Dominique Boucher ----- Original Message ----- From: "Per Bothner" To: "Rafik Naccache [TNTeam]" , kawa@sourceware.org Sent: Thursday, February 18, 2016 1:57:39 PM Subject: Re: What is the Development Environment of Choice for Kawa? On 02/18/2016 08:18 AM, Rafik Naccache [TNTeam] wrote: > Hi, > > Coming from Clojure Land, I am experimenting with various scheme implementations, guile, chicken, racket,... > > As I am experimenting Kawa, I was surprised to see how this scheme can actually beat Clojure in terms of speed and elegance, and want to use it in a serious hobby project in which I have to interact with a great share of imperative Java, a setup that would make Clojure suffer... > > But then, I can't find what tool is commonly used by the community to develop Kawa: is it emacs with comint? is it slime with the little swank glue-code? maybe something else? Tooling is Kawa's weak spot - though its compile-time warnings and errors are better than most "dynamic languages" IMO. I'm pretty old-school, so I mostly use Emacs (mainly just editing), the REPL, and print statements. (Very rarely I might use jdb to track down an infinite loop.) OTOH I write more Java (and lately JavaScript) than I write Scheme ... A related weakness is connected to Kawa's strength: Kawa does a fair amount of compile-time optimization and inlining. This causes problems in interactive development: you load a function or module, and then edit it and reload it. Other functions that depend on the change code may no longer work. A partial work-around is to use the --no-inline command-line option. I do have plans to improve the situation, though a combination of extra indirection and automatic re-compilation of dependencies. There are various Emacs packages and/or IDE plugins that can be used. There is this plugin for Eclipse: https://github.com/schemeway/SchemeScript However, I don't think it's actively maintained, though the git repo has seen a few semi-recent updates. I haven't tried it recently - a status report would be interesting. There are also various Emacs packages that can be used, though I don't have much experience with them. I have been working recently on improving the Kawa repl, both using DomTerm and using jline2/jline3. I have some not-quite-working code - and plenty of ideas :-) -- --Per Bothner per@bothner.com http://per.bothner.com/