From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: GNU Guile 2.1.7 released (beta) Date: Fri, 24 Feb 2017 15:02:21 +0100 Message-ID: <87d1e7vg9e.fsf@pobox.com> References: <87y3x3zt6v.fsf@pobox.com> <87tw7kviu6.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487944975 8806 195.159.176.226 (24 Feb 2017 14:02:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2017 14:02:55 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-devel@gnu.org To: guile-user@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Feb 24 15:02:49 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1chGSK-0001VL-I9 for guile-devel@m.gmane.org; Fri, 24 Feb 2017 15:02:44 +0100 Original-Received: from localhost ([::1]:37538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chGSQ-00074O-GB for guile-devel@m.gmane.org; Fri, 24 Feb 2017 09:02:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1chGSA-0006vA-LA for guile-devel@gnu.org; Fri, 24 Feb 2017 09:02:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1chGS6-00009S-Nt for guile-devel@gnu.org; Fri, 24 Feb 2017 09:02:34 -0500 Original-Received: from pb-sasl1.pobox.com ([64.147.108.66]:53226 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1chGS6-000090-KO; Fri, 24 Feb 2017 09:02:30 -0500 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id AD4685CEA4; Fri, 24 Feb 2017 09:02:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=E9o+GLL/8+s6otv2I+K6yPgNMXo=; b=SloLO1 ZLuCS+j0X15UMCD68NvhMInZQTMEqTucLznBTB+6dErhGUorzsS8GxA8C2sMiD2M CipnET7WvmN7ElfMzG7gzA9+bq5okdhPO9oQIHoT3x4bk79vyV++kYUQ9hcqK3gv tzN0mtTbBsQrPiUqjtvBxPwFLxg4+lqD7utL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=BbewWUkh5JRQG6tcTbVuwtL9rh4EL/7F 0CuYUEpleN2IaYzL1OLZOZu5Fd9aXXU5CqifUGaBCPDE8mxq4SOg6HJhaQeiBmSe l+JqDEt3hqzYFf8JrzLo9/BfbPCtfR3kp0GEM52wgmRXE1vIpTJM7S+Uc+LHJdUx kz0Ts7WN2jM= Original-Received: from pb-sasl1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id A58B55CEA3; Fri, 24 Feb 2017 09:02:29 -0500 (EST) Original-Received: from clucks (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id A31065CEA2; Fri, 24 Feb 2017 09:02:28 -0500 (EST) In-Reply-To: <87tw7kviu6.fsf@pobox.com> (Andy Wingo's message of "Thu, 23 Feb 2017 19:54:25 +0100") X-Pobox-Relay-ID: E0C820DC-FA99-11E6-8D0D-CDEC6462E9F6-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.66 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:18947 gmane.lisp.guile.user:13319 Archived-At: On Thu 23 Feb 2017 19:54, Andy Wingo writes: > * Foreign objects. In or out? Let's start a subthread. SMOBs have many problems: * they are limited in number (255 including guile's smobs) * SMOB types are only creatable from C (in a time where anything done in C should be doable in Scheme) * SMOBs can only be constructed from C * SMOB fields are only accessible from C * SMOB markers are ~~~~~~gnarly~~~~~~~ * SMOB finalizers are tricky. Well finalizers are tricky in general but for SMOBs specifically they can see other objects that have already been finalized (or which are being concurrently finalized) and thus have called their own free() functions, which can corrupt memory. The situation with SMOBs is good if you don't specify mark procedures (practically deprecated since Guile 1.8) and your finalizer doesn't touch additional GC-managed objects that themselves have finalizers (hard to determine) and if your finalizers are threadsafe (ha ha ha ha ha ha). The manual didn't really discuss any of these problems. And then there's the issue of the very 1980s interface of SMOBs. Let's not mention markers! So you look at this whole situation and, this is an interface headed for deprecation, right? I mean surely we can do better -- or at the very least we can do the same but in a more comprehensible way. So I made the "foreign object" interface to do just that. See the docs here: https://www.gnu.org/software/guile/docs/master/guile.html/Defining-New-Foreign-Object-Types.html https://www.gnu.org/software/guile/docs/master/guile.html/Foreign-Objects.html The former is in the introductory "using Guile from C" section and the latter is the reference. Compare to 2.0: https://www.gnu.org/software/guile/manual/html_node/Defining-New-Types-_0028Smobs_0029.html - it tells users to use mark functions (this is bad advice in general) - it doesn't mention much about threads when it talks about finalization https://www.gnu.org/software/guile/manual/html_node/Smobs.html#Smobs - not really linked to from the previous section?? (This one is in "API" and the other is in "Programming in C") - recommending scm_gc_free - scm_markcdr???? So foreign objects fixes the problems mentioned above and also makes the whole facility more explainable. It effectively replaces SMOBs; it's a nicer interface in all regards. I think it would be fine to continue having foreign objects going forwards. It's supportable just fine and strictly better than smobs (unless you need a mark function, in which case SMOBs are still there for you). It could be that these foreign objects don't fulfill all use cases, such as packed structs with C layouts. Oh well; can't win them all. We can work on this more in the future I think. Thoughts? :) Andy