From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-f67.google.com (mail-ua1-f67.google.com [209.85.222.67]) by sourceware.org (Postfix) with ESMTPS id 074473842400 for ; Thu, 16 Jul 2020 00:03:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 074473842400 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=alum.mit.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=j.r.hope@gmail.com Received: by mail-ua1-f67.google.com with SMTP id u33so1193690uad.9 for ; Wed, 15 Jul 2020 17:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u26/xJY5Ht+2bOeV4xMrrL8YyEI5nveG9z5XVD/H0QY=; b=GPyau5Zp4PNPSE///bl6Yoz9yBC2zLyjpSSkxUIJfX8KgcZ5uuc0CYbz/qfbbnq+EO GIH25hF6AZz0UIFtoix0mABZi3t+lG34rppVP1ThtT0lEfT7BL31qW95eBvTHNpMNTeS x2a/8tw6uOcNg1T9+20gdqHiWpitNhiN2p9vxpu+Bw+blAM2LMZvnhuS8PS749kjaHB7 Y7INw1lTRuEvZDxxPmBIHqRCKvZKB7weB7t6aBcaQICjabiluHkmH7ulB0tloKL0X24p sfCdk4EmWcANIh4XPHcvlXLEyfDiLyu9/RDRnlUpU5tzYalAFi6bcxCbpb4OLbc1e5HX D4lg== X-Gm-Message-State: AOAM5330pfYfz36ozgMSFZ3Iib1zT0VSpyUYqyHa7tyyVLYCNABCDEA/ TfCqyx9j81Z6g+DttNjO1p2K8/kwuKaGqbuuOgGuJPaG X-Google-Smtp-Source: ABdhPJw7PobOxmmRB22K+Id3IfeUho9VkpmGnrfoJDT9mL+WgOIy4bN+9Lr9y5AdBYRAMPjFOQoVbfT/XceH4MavhU4= X-Received: by 2002:ab0:481:: with SMTP id 1mr1451318uaw.11.1594857788300; Wed, 15 Jul 2020 17:03:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jamison Hope Date: Wed, 15 Jul 2020 20:02:57 -0400 Message-ID: Subject: Re: SRFI 170 (POSIX API) for Kawa To: kawa mailing list Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 00:03:10 -0000 On Wed, Jul 15, 2020 at 12:16 AM Per Bothner wrote: > > On 7/14/20 2:10 PM, Duncan Mak wrote: > > it's pretty clear that we won't be able to support the entirety of the SRFI 170 API using just Java classes. If we want to achieve that, we'll probably have to use JNR-Posix. > > > > With JNR-Posix, Per's comments about shipping native code will become a thing. > > I don't mind an optional (configurable) dependency on jnr or jnr-posix, but I don't think > it should be a required or default dependency. > > I don't have much feel for how popular or common JNR is - it seems to be > a project that is in semi-maintenance mode, and not on any kind of "standards track". > I haven't done anything with it. > > That doesn't seem we can't make use of it, of course. I agree it shouldn't be a required dependency. But it would also be handy to be able to use the SRFI in conjunction with a stock binary Kawa release, and not have to do a custom configuration. Per, can the srfi loading in ImportFromLibrary.java cross jar boundaries? If so, one option might be for SRFI97Map to map 170 to some other named class that isn't included in kawa.jar, and then provide a separately-compiled kawa-srfi170.jar or whatever that did rely on JNR-Posix or other such native code. Then if that other jar is in the CLASSPATH, then (import (srfi 170)) loads/uses it, and if not, then it doesn't work, or maybe we instead fall back on a Java-only subset. I've never used JNR. My impression is that it's like JNA but.. better? Or at least newer? I used to use JNA to access some C libraries, and it worked fine for what I was doing at the time. Is JNR-Posix the only viable option? Duncan, can you post a listing of which SRFI-170 functions are / are not doable using just standard Java with no third-party/native code? It'll help to weigh the pros and cons of introducing a new dependency. > Please us and Duncan know (here) whether SRFI-170 or other Posix bindings would be > useful to you. It's really a shell thing and not a POSIX thing per se, but I have some scsh scripts lying around that made heavy use of process pipelines and &&, which seem to have been omitted from SRFI-170. Kawa supports pipelines via pipe-process, but is there an equivalent to scsh's &&? As in: (let ((echo (if dry-run? '(echo) '()))) (&& (,@echo cmake ,@(cmake-opts) ,@opts ,src-dir) ,(if verbose? `(,@echo make -j ,ncpu VERBOSE=1) `(,@echo make -j ,ncpu))) This almost works: (define-syntax && (syntax-rules () ((_ e ...) (and (process-exit-ok? e) ...)))) (&& &`{date} &`{true}) => #t (&& &`{date} &`{false}) => #f but it loses the output of each command. I'm guessing it would need a validate-apply thing just like pipe-process in order to inject "out-to: 'inherit" to each one, but I haven't figured out the right incantation. As for what is covered by SRFI-170, for the most part they aren't really things I would use very often, beyond what's already available in Kawa's file system interface. But that's not a vote against proceeding with this effort: I've contributed several SRFI implementations to Kawa, and I hardly ever use any of them, either. -- Jamison Hope