From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88790 invoked by alias); 22 Feb 2020 16:40: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 88777 invoked by uid 89); 22 Feb 2020 16:40:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:4.90_1, HX-Languages-Length:1100 X-HELO: aibo.runbox.com Received: from aibo.runbox.com (HELO aibo.runbox.com) (91.220.196.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 22 Feb 2020 16:40:48 +0000 Received: from [10.9.9.203] (helo=mailfront21.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1j5XpY-0002L1-4p; Sat, 22 Feb 2020 17:40:44 +0100 Received: by mailfront21.runbox with esmtpsa [Authenticated alias (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1j5XpV-0005sE-KU; Sat, 22 Feb 2020 17:40:37 +0100 Subject: Re: SRFI 170 (POSIX API) for Kawa To: Duncan Mak , Lassi Kortela Cc: kawa mailing list , srfi-170@srfi.schemers.org References: From: Per Bothner Message-ID: Date: Sat, 22 Feb 2020 16:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-q1/txt/msg00023.txt On Sat, Feb 22, 2020 at 4:46 AM Lassi Kortela wrote: > Is anyone working on implementing SRFI 170 for Kawa yet? Since Kawa is > Java-based instead of C-based, and uses pathname objects as well as a > per-thread parameter object to store the current directory, it would > make for a good test case. It might be interesting to see how much could be implemented in portable Java, without digging into native (C/C++) code. Kawa currently does not contain native code, which means we can make a single cross-platform "binary release". That doesn't mean I'll rule out having optional features that depend on native code, but I would prefer to stick to no native code in the default build. There are no doubt large parts of SRFI-170 that could be implemented without native code, but I haven't done the effort to see what the issues are. If someone wants to look into to what extent SRFI-170 can be mapped into Java APIs that would be interesting, but I'm not planning to do that study myself. -- --Per Bothner per@bothner.com http://per.bothner.com/