From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: Guile foreign object interface Date: Thu, 09 Mar 2017 13:09:40 +0100 Message-ID: <87y3webqij.fsf@gnu.org> References: <1644439317.409814.1488469678720.ref@mail.yahoo.com> <1644439317.409814.1488469678720@mail.yahoo.com> <87shmpcibe.fsf@gnu.org> <87r32988we.fsf@pobox.com> <877f40svma.fsf@gnu.org> <87r32867ni.fsf@fencepost.gnu.org> <87lgsfjxhi.fsf@gnu.org> <87o9xb4bmn.fsf@fencepost.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1489061435 26761 195.159.176.226 (9 Mar 2017 12:10:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Mar 2017 12:10:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Mar 09 13:10:31 2017 Return-path: Envelope-to: guile-user@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 1clwtr-0006ZC-79 for guile-user@m.gmane.org; Thu, 09 Mar 2017 13:10:31 +0100 Original-Received: from localhost ([::1]:33554 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clwtx-0004rW-47 for guile-user@m.gmane.org; Thu, 09 Mar 2017 07:10:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clwtO-0004pn-UU for guile-user@gnu.org; Thu, 09 Mar 2017 07:10:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clwtL-0007me-ON for guile-user@gnu.org; Thu, 09 Mar 2017 07:10:02 -0500 Original-Received: from [195.159.176.226] (port=60948 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clwtL-0007mC-HD for guile-user@gnu.org; Thu, 09 Mar 2017 07:09:59 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1clwt4-00028n-2o for guile-user@gnu.org; Thu, 09 Mar 2017 13:09:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 98 Original-X-Complaints-To: usenet@blaine.gmane.org X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 19 =?utf-8?Q?Vent=C3=B4se?= an 225 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Cancel-Lock: sha1:3lib3vzdOryDjlpezTrMC9oaUjw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:13456 Archived-At: David Kastrup skribis: > ludo@gnu.org (Ludovic Courtès) writes: > >> David Kastrup skribis: >> >>> ludo@gnu.org (Ludovic Courtès) writes: >>> >>>> Andy Wingo skribis: >>>> >>>>> I am not so sure about about this one. I think it's not accurate to >>>>> characterize beginning to replace a 25-year-old C API (SMOBs) as >>>>> "churn". >>>> >>>> I think the point is that there’s lots of code out there that rely on >>>> SMOBs and we shouldn’t break it overnight, precisely because that API >>>> is this old. >>>> >>>> Of course, I agree that pushing users towards an improved API is the >>>> right thing long term, no argument here. >>> >>> Shrug. LilyPond has all of its SMOB usage condensed into few C++ >>> classes, so it is comparatively easy to migrate to a different API as >>> long as it offers comparable functionality. >>> >>> Which it doesn't (namely the ability of marking objects reached through >>> STL-managed data structures). So it's pretty pointless to "push users >>> towards an improved API" and hardly "the right thing". >> >> Thanks for your feedback, this is a kind of use case we’d like to >> support. >> >> I’m sure we already discussed it and then I forgot, but would anything >> prevent the use of specific C++ allocators in this case? The STL data >> structures could be allocated on GC-scanned memory, in which case mark >> procedures are unneeded. > > We are not talking about STL data structures containing SCM values but > data structures containing other data structures and pointers to other > data structures. You cannot sensibly garbage collect when whole memory > areas in which allocation and deallocation is done are in GC-scanned > memory and there is no difference between data structures that have been > freed and data structures that haven't. Not sure what you mean. >> If this cannot be done, there’s always the possibility of having a >> weak hash table to keep the C++ and Scheme object life cycles in sync. >> That happens even with C APIs that record a pointer to an object we >> care about in non-scanned memory. Since 2.0 was out I’ve never used >> mark procedures for in C bindings. >> >> Thoughts? > > LilyPond is a large-scale application which will eat up a significant > ratio of the available address space in 32 bit applications and will > process, in a documentation run, thousands of files with little overlap. > Already in Guile 1.8 where _only_ the stack is conservatively marked and > gc is called explicitly at known points of low-stack usage, we have > occasional false positives in garbage collection (the debugging runs > flag them). With large memory areas being conservatively scanned, this > is going to get a whole lot worse. This sounds like speculation to me. I don’t think we’ve seen slowdowns when Guile then 1.9 switched to BDW-GC, quite the opposite. > The point of time where it makes sense to try to evaluate the impact or > feasibility of such functionality removals (and Boehm GC _does_ support > finalization) is when LilyPond is otherwise running fine on Guile 2. > With the current slowdown by a factor of 5-10 and a number of other > problems preventing the LilyPond test suite from running, there just > isn't any setup where a useful evaluation could take place. LilyPond on Guile 2.0 is 5–10 times slower than on 1.8? > As there is no technical necessity for planning the wreckage of existing > functionality when there hasn't even been a stable release containing > the prospective successor, I cannot see a viable point in raising yet > more hurdles for existing applications to migrate to Guile 2 rather than > bite the bullet and fork Guile 1.8 in order to actually have some > dependable functionality to base other work on. Note that SMOBs are still around in 2.2, not even deprecated, only discouraged. >> As an aside, please keep the tone friendly as is the norm on this >> mailing list. > > Disagreement is not the same as unfriendliness. I agree. However I found the tone of your messages patronizing and aggressive, assuming bad faith and incompetence on the side of the Guile developers (“planning for wreckage”, “pretty pointless”, etc. etc.) This is not OK on the Guile mailing lists. Thanks, Ludo’.