From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Thu, 15 Oct 2015 23:11:30 +0000 Message-ID: References: <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> <83wq3k3kl4.fsf@gnu.org> <85bnkwil1c.fsf@stephe-leake.org> <83pp9cwky8.fsf@gnu.org> <85a90ggf2d.fsf@stephe-leake.org> <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> <5610ED13.1010406@dancol.org> <56117F37.9060808@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2668251007605222ccdf2 X-Trace: ger.gmane.org 1444950731 20941 80.91.229.3 (15 Oct 2015 23:12:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Oct 2015 23:12:11 +0000 (UTC) Cc: Eli Zaretskii , Daniel Colascione , Stephen Leake , Emacs development discussions To: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 16 01:12:11 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 1Zmrgs-0007M3-Gh for ged-emacs-devel@m.gmane.org; Fri, 16 Oct 2015 01:12:06 +0200 Original-Received: from localhost ([::1]:50086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zmrgr-0003st-Vu for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 19:12:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmrgX-0003r7-Qg for emacs-devel@gnu.org; Thu, 15 Oct 2015 19:11:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmrgW-0005SJ-OC for emacs-devel@gnu.org; Thu, 15 Oct 2015 19:11:45 -0400 Original-Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]:35574) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmrgU-0005QF-S6; Thu, 15 Oct 2015 19:11:43 -0400 Original-Received: by lffy185 with SMTP id y185so54227518lff.2; Thu, 15 Oct 2015 16:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=jctamfZHyZkP+voZ5oMxSO0aAaH8lL5BYVx37XtRUNc=; b=oLHkkhc+segeEPLqwrs/zb5RSBN12ZyGN5ay5I1fQYV/IDwc/8ACKBLT7x0ji4oXIK 8cV6F8lfRIzKbiiVTDqC2L89vAtqJvGd6Jw4qM0pShutrl1WXNhVWP6WVVmXVrPTXRML 1/BZUTE47hsxeIiHHuFxcO0S07mIMbaYvug8lOw5g7lC5y1I8PYPh2NESeDZn8eEOQyp ja6KwDJLOWmPy/3G48wmZG8GpCWhhrPDu91VVsnpWZRhSc4XpfgploidPmNBjJovyK1U Jy+5+gW/bpWjLoJg/XzbGVIol0qZEha0pjddrMkMM346sKZ2p9Y42fjgFmiZoqALZMu4 xt6w== X-Received: by 10.180.11.1 with SMTP id m1mr1147710wib.69.1444950702094; Thu, 15 Oct 2015 16:11:42 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c07::22b 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:191703 Archived-At: --001a11c2668251007605222ccdf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aur=C3=A9lien Aptel schrieb am Do., 15. Ok= t. 2015 um 12:44 Uhr: > On Thu, Oct 15, 2015 at 2:25 AM, Philipp Stephani > wrote: > > Agreed. I've implemented Daniel's suggestion on the tls-error branch, i= t > > seems to work fine (but note that environments are now no longer global= , > so > > storing away emacs_values without global references now will lead to > > undefined behavior). > > Yeah I just realized that. The nice thing with just casting is its the > same memory object and the stack-scanning GC just works. Having the GC > is nice... > Until you change the GC algorithm to a precise GC or reference counting and cause all modules to crash, leak memory, or worse. This is exactly the kind of dependency on implementation details that we want to avoid with a clean module interface. > Again, IIUC, the only problem is on 32bit with wide-int, which is off > by default. > > Even if sizeof(Lisp_Object) =3D=3D sizeof(void*), you still need the guaran= tee that (Lisp_Object)((void*)0) is an invalid Lisp object. > > Let's see what will get accepted upstream. > > That's sneaky... but this is how the free software world works I guess... > I don't think it's sneaky. The opinions of everyone are known and have been discussed ad nauseam in public. Either it gets accepted or it doesn't. --001a11c2668251007605222ccdf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Aur=C3= =A9lien Aptel <aurel= ien.aptel+emacs@gmail.com> schrieb am Do., 15. Okt. 2015 um 12:44=C2= =A0Uhr:
On Thu, Oct 15, 2015 at 2:2= 5 AM, Philipp Stephani <p.stephani2@gmail.com> wrote:
> Agreed. I've implemented Daniel's suggestion on the tls-error = branch, it
> seems to work fine (but note that environments are now no longer globa= l, so
> storing away emacs_values without global references now will lead to > undefined behavior).

Yeah I just realized that. The nice thing with just casting is its the
same memory object and the stack-scanning GC just works. Having the GC
is nice...

Until you change the GC algo= rithm to a precise GC or reference counting and cause all modules to crash,= leak memory, or worse. This is exactly the kind of dependency on implement= ation details that we want to avoid with a clean module interface.
=C2=A0
Again, IIUC, the only problem is on 32bit with wide-int, which is off
by default.


Even if sizeof(Lisp_Object) =3D=3D siz= eof(void*), you still need the guarantee that (Lisp_Object)((void*)0) is an= invalid Lisp object.
=C2=A0
> Let's see what will get accepted upstream.

That's sneaky... but this is how the free software world works I guess.= ..

I don't think it's sneaky. T= he opinions of everyone are known and have been discussed ad nauseam in pub= lic. Either it gets accepted or it doesn't.
=C2=A0
--001a11c2668251007605222ccdf2--