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 modules: emacs-module.c and signaling errors
Date: Thu, 26 Nov 2015 22:33:39 +0000
Message-ID:
References: <83k2p7xk13.fsf@gnu.org> <87wpt7p369.fsf@tromey.com>
<83d1uzxgvw.fsf@gnu.org> <5654D7CF.90001@cs.ucla.edu>
<87si3vox7j.fsf@tromey.com>
<56555B52.3030703@cs.ucla.edu> <837fl6xa02.fsf@gnu.org>
<5655F10D.9080805@cs.ucla.edu>
<83vb8ovkc5.fsf@gnu.org>
<83a8q0vgb9.fsf@gnu.org>
<83si3stuzn.fsf@gnu.org>
<83poywtsxl.fsf@gnu.org>
<565777AE.6030204@cs.ucla.edu>
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a1130cd2431d8e80525792bc7
X-Trace: ger.gmane.org 1448577241 6677 80.91.229.3 (26 Nov 2015 22:34:01 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 26 Nov 2015 22:34:01 +0000 (UTC)
Cc: Emacs developers
To: Paul Eggert , Eli Zaretskii ,
Stefan Monnier ,
Daniel Colascione
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 26 23:33:59 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 1a2570-0007lQ-I3
for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 23:33:58 +0100
Original-Received: from localhost ([::1]:53382 helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1a256x-0000xG-QZ
for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2015 17:33:55 -0500
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36189)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1a256u-0000xB-Vt
for emacs-devel@gnu.org; Thu, 26 Nov 2015 17:33:54 -0500
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1a256t-0005g4-Rn
for emacs-devel@gnu.org; Thu, 26 Nov 2015 17:33:52 -0500
Original-Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:38081)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1a256s-0005e9-1s; Thu, 26 Nov 2015 17:33:50 -0500
Original-Received: by wmec201 with SMTP id c201so37555089wme.1;
Thu, 26 Nov 2015 14:33:49 -0800 (PST)
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=7wU+nWvOACYNMdFR/9U4RNkffrt4BVIAQIgu0a9ZqKc=;
b=lGvBV7liUNZ9dM9+XDtwclzEaG7DF9OHt1C+lYhIYqYZBM6Ie63NUjsQrE1t5Q83Nj
4tYnC+a+GayB/HOkECVoJZKb3ccSy5thoLyPeG86nhyV2fK8qxae4i7TVC5pkK5kmvGQ
GuetZszAiEREQt81MgT7F1NcsFAkZHmJs+QZTtaAImwd5+QZmiPPoTmIPW84mGqmNOJX
XJWlgw2IWXwZ2fGRL38onxCQqkTdwnLidteP+RuV+YBOAuq9NKNjENEJu+doRGmjAgaL
eBqT4YgxubyYyVZLn34bQ/LlmngHGYcGX/OBxS+FTEyC8dFUOgmiTG4lXOsAjhtWINS/
RoFQ==
X-Received: by 10.194.116.170 with SMTP id jx10mr24607880wjb.166.1448577229509;
Thu, 26 Nov 2015 14:33:49 -0800 (PST)
In-Reply-To:
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-Received-From: 2a00:1450:400c:c09::234
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:195323
Archived-At:
--001a1130cd2431d8e80525792bc7
Content-Type: text/plain; charset=UTF-8
Philipp Stephani schrieb am Do., 26. Nov. 2015 um
23:29 Uhr:
> Paul Eggert schrieb am Do., 26. Nov. 2015 um
> 22:21 Uhr:
>
>> Eli Zaretskii wrote:
>> > It's not obvious to me, sorry. The costs of the current code are
>> > minimal, and the advantages to have the "raw" functionality in
>> > addition to what we have aren't clear-cut.
>>
>> My admittedly vague impression is that Stefan's approach would be
>> friendlier to
>> module authors who want to write code that feels like Emacs's current C
>> code.
>> This should be a plus, no?
>>
>> I don't fully understand why the current emacs-module.c is as complicated
>> as it
>> is, to be honest. I know it has something to do with C++ exception
>> handling,
>> but the details still escape me. But really, we should support C modules
>> well
>> too, as C is still the lingua franca for low-level software integration.
>> And
>> "well" does not mean "every time you call a function you then have to
>> call some
>> other function to see whether the first function worked".
>>
>>
> Please see Daniel's original design and the follow-up discussions:
> https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00960.html
>
Also this subthread with even more discussion:
https://lists.gnu.org/archive/html/emacs-devel/2015-09/msg00540.html
--001a1130cd2431d8e80525792bc7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Eli Zaretskii wrote:
> It's not obvious to me, sorry.=C2=A0 The costs of the current code=
are
> minimal, and the advantages to have the "raw" functionality =
in
> addition to what we have aren't clear-cut.
My admittedly vague impression is that Stefan's approach would be frien=
dlier to
module authors who want to write code that feels like Emacs's current C=
code.
This should be a plus, no?
I don't fully understand why the current emacs-module.c is as complicat=
ed as it
is, to be honest.=C2=A0 I know it has something to do with C++ exception ha=
ndling,
but the details still escape me.=C2=A0 But really, we should support C modu=
les well
too, as C is still the lingua franca for low-level software integration.=C2=
=A0 And
"well" does not mean "every time you call a function you the=
n have to call some
other function to see whether the first function worked".
=
--001a1130cd2431d8e80525792bc7--