From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Fri, 06 Mar 2015 10:22:30 -0800 Message-ID: <54F9F066.6010902@dancol.org> References: <54E0A40F.5080603@dancol.org> <83sie7un20.fsf@gnu.org> <54E0D181.2080802@dancol.org> <83r3trulse.fsf@gnu.org> <54E0D7E0.305@87.69.4.28> <83h9unukbg.fsf@gnu.org> <54E0DEF8.7020901@dancol> <83egpruiyp.fsf@gnu.org> <54E0FF93.2000104@dancol.org> <833865vp4d.fsf@gnu.org> <54E2355A.90@87.69.4.28> <83vbj1u020.fsf@gnu.org> <54E24CA4.9020601@dancol.org> <83h9uk7ddb.fsf@gnu.org> <54E382A5.5030408@dancol.org> <54F789B2.6030105@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X5f0rHv10ioxgfBiahAGCQTLDOJMRoLIK" X-Trace: ger.gmane.org 1425666188 11044 80.91.229.3 (6 Mar 2015 18:23:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Mar 2015 18:23:08 +0000 (UTC) Cc: =?windows-1252?Q?Aur=E9lien_Aptel?= , Eli Zaretskii , Stephen Leake , Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 06 19:23:07 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YTwtr-0004qR-PN for ged-emacs-devel@m.gmane.org; Fri, 06 Mar 2015 19:23:03 +0100 Original-Received: from localhost ([::1]:59713 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTwtr-000872-9x for ged-emacs-devel@m.gmane.org; Fri, 06 Mar 2015 13:23:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTwtc-00086u-BN for emacs-devel@gnu.org; Fri, 06 Mar 2015 13:22:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTwtZ-0002I4-SK for emacs-devel@gnu.org; Fri, 06 Mar 2015 13:22:48 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:47562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTwtZ-0002F2-HM; Fri, 06 Mar 2015 13:22:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wob8jhZb2oJ4oLvgxKlMtsLvAqSwp4QB7+n9gEyaJwY=; b=au3L/4YU10VDZ6GBkj1G/rCPOB0/p2zWPOsmbNhNoZJfxkbYh4yHdOxu0ReqLSz+hWOLY7vE6+YMaDUOW6l8x3V2cl4RFYvCnMmRnmQRxICnakIT+DbnRKqGVwC1LUhgK8Leenv42fsGV6zS1wxm0xy9+oDvlpI7lr5Dj2A7SLgfFJzsNWMUAguHVDFKDvcACpCDTglDHxg4C0rPppJjN5BEW9AN7z/Czf+2kS9JxXQbtaxUtZDZ3MsmPiR89dMiFi6ZNvygvGTImIB1xiPB9eDFHhTZ5DKd8UlZgawtcwhhgKj+vphY4BUMkaNvYYHMiMTzIDlYqSUal13Mz1nNEg==; Original-Received: from [2620:10d:c081:1101:2ab2:bdff:fe1c:db58] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YTwtR-0002Ne-TD; Fri, 06 Mar 2015 10:22:37 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183703 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X5f0rHv10ioxgfBiahAGCQTLDOJMRoLIK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/05/2015 09:14 PM, Stefan Monnier wrote: >>>> * fixnum <-> int64_t is the only type conversion supported >>> Not sure I understand: can the C side see "Lisp_Object" (presumably a= s >>> an opaque type)? >> As I'm imagining the system, no. Access is indirected. That insulates = C >> code from Emacs GC requirements and lets us easily support global >> references. >=20 > But that forces a completely manual management of Lisp_Object > references, making the interface a lot more painful to use. > I must prefer exposing staticpro and conservative stack scanning. Reasonable people can differ on the conservative scanning issue (JSC does it; V8 and Java don't). If we bake the assumption of conservative scanning into the interface, we're going to regret it later. In practice, manually managing references is no trouble at all since most Lisp->C code is call-response, and we automatically unwind references when C functions return. I have to insist on not requiring staticpro, at least in its present form. Registration of new GC roots (i.e., global references) must be dynamic. You can't possibly predict the reference models modules might want to use. --X5f0rHv10ioxgfBiahAGCQTLDOJMRoLIK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU+fBnAAoJEN4WImmbpWBlGGQP/0dvZqIChojzsSdwnvx/v5GH uP60RSiASNhX1B6/tunOIaU6l2qoOSS3ckLcvn0A1jmxCVrDiH3QmjVecgNT1UDx ke8mwZJGQz9iCAgRRH2KYiyo0MP7qcRsEpeSvs4QYIxKnkZRrkFHNaj1+2WXAhGg TBdjWImSABRsuEPigx6SXIW1CJJxTbh8fdq8baKNd2JP7HqflUv76K5rTNKTfQZe foozkrEsmFYYN3IjxxBm18/uFG0Ltw7eJfuVFZ/UL83cbc5ry0j9VdvscMDoL4zU POX+kigM0KpOP1CgaRKpVrSTGOa4lIGpr7iHZvAQi2CbFLKlChJW6ycfL5a3CXs4 28f627O9evCRvk8mJsNS90Zq8hJhtM04kOD40H0OUaO1dqo63vobuKuPXui6n8Ew QyToQVEJ7UXuKYElsZzKDzlow5EJntMz3VqRS5ojy7TzDzwMLV4E2ATVLEo9XNBf zF6KtvE5yL8f6u3YrYJ7emHjxcxsIJZFABuGqQ/xiEdCAMYw0tRonLGhlgEdpSo6 kXMlA5xsnzthe5l8Grvu5uuffzvnRHla9pmr0JzTfOdPWzEd2K/XYRLqK0+e9QO2 QXmFSe6LNKa2J8/DBz+iSxk112UmzGtQWW9d0rftD07x/tZpiHhR9aLCqu5f2p// yPPADsDYV2Gq2gmNWdoT =m7on -----END PGP SIGNATURE----- --X5f0rHv10ioxgfBiahAGCQTLDOJMRoLIK--