From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Elias_M=C3=A5rtenson?= Newsgroups: gmane.emacs.devel Subject: Re: GNUS Kerberos support, native GSSAPI? Date: Thu, 9 Feb 2017 21:02:11 +0800 Message-ID: References: <87a89vmvd5.fsf@fastmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c11bf24e3f9be0548189617 X-Trace: blaine.gmane.org 1486646294 23488 195.159.176.226 (9 Feb 2017 13:18:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Feb 2017 13:18:14 +0000 (UTC) Cc: emacs-devel To: Joakim Jalap Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 09 14:18:10 2017 Return-path: Envelope-to: ged-emacs-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 1cbobw-0005ms-Pr for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2017 14:18:09 +0100 Original-Received: from localhost ([::1]:37863 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cboc2-0006PR-77 for ged-emacs-devel@m.gmane.org; Thu, 09 Feb 2017 08:18:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cboMX-0000fh-OI for emacs-devel@gnu.org; Thu, 09 Feb 2017 08:02:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cboMW-0002FT-NI for emacs-devel@gnu.org; Thu, 09 Feb 2017 08:02:13 -0500 Original-Received: from mail-ua0-x229.google.com ([2607:f8b0:400c:c08::229]:35980) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cboMW-0002FM-IU for emacs-devel@gnu.org; Thu, 09 Feb 2017 08:02:12 -0500 Original-Received: by mail-ua0-x229.google.com with SMTP id 96so2171844uaq.3 for ; Thu, 09 Feb 2017 05:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=83OxIpPapmtyYpNuDKoGjTRG2ruvMCNE+reMW81MTYU=; b=Tv0sK5D3R5QTzaw0aD8+WH2gpWyEDM8lYLPwTyjkE0CPxccyaX44XT8ckR450PBqJt L7TNzwkUpg90CzQB14Sq5+awwG4uXBrk/IHM61q+Md8oitFP71qiJJrnPPxChSmAWkCe fSEI3dAdVO6UtxwUPZ6gCzHhA3x0bCBNHo8KDMp3ylfLtAJKmsUZ0MYehUQNjfed8DOx bcGL2p1l7NrjWilTL0rjGb1KGfw9+8f+3kh/8w6F3hysCaNRHoEsvVE5J4c+tISkdVsR WX/C+kwfuTjot0/8UV28g+AzgXSosuOXlfu7sfuUFrS8djhf8jtKyyzyrNZYUjgiwyLk fc5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=83OxIpPapmtyYpNuDKoGjTRG2ruvMCNE+reMW81MTYU=; b=CBkTwhExDTmN7g2CRDRU8ykDhx+KamZsmq54QkzUPfjAoQihAOpRZ2cAagTqB/Vl+N H8ruTapTpyhL5aH/8saZDelnmbxLP/pC6xIoMDIvW8DCb0nfAlq2AqZoofVqHq62vPqB /Q5JX1FjRE7ELCEbVGvZFZKm+FAVR3SiFBA0nbOW5xXG4iLadO+JVcAUfecRqfVtg8OU VJoAI8rw0HP49ViQDBmHv7gsM/6OlmvbxGsWsraRGVNZjmg7Lizh0Z9gMFMgtJ0XZ07q iKq9deEZxCGPSw1yWLAsRMDDoMcXCwLaujpTfYfLZIS44O2rP2ePpskgFhflhuJqpMJe UOPw== X-Gm-Message-State: AMke39m+dd5X+MTtmbyUiM/hTSgn++snqlayBV1X91Atp/8BKOGJr55skojxBKeq0JOjqRY/qrtKh1nnnzUXJw== X-Received: by 10.176.69.172 with SMTP id u41mr1558834uau.164.1486645331487; Thu, 09 Feb 2017 05:02:11 -0800 (PST) Original-Received: by 10.103.131.215 with HTTP; Thu, 9 Feb 2017 05:02:11 -0800 (PST) In-Reply-To: <87a89vmvd5.fsf@fastmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400c:c08::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:212163 Archived-At: --94eb2c11bf24e3f9be0548189617 Content-Type: text/plain; charset=UTF-8 On 9 February 2017 at 19:55, Joakim Jalap wrote: This is really cool :) Just looking over the code quickly it seems like > it would be useful to extract some of the functions in your module as a > sort of "emacs module lib". I mean things like bind_function, xcar, > xcdr, lisp_push (which is cons) and so on. Shouldn't everybody who > writes a module want most of these? > > Just a thought :) > Thanks! And yes, I agree. This is my first attempt at writing something that uses the module API, and these are definitely functions that I cannot see anyone writing a module would not end up reimplementing. In fact, I'd go as far as suggesting that some of the boilerplate should be provided by emacs-module itself. In particular, having to do env->intern(env, "nil") just to get a reference to nil is a bit crazy. I tried putting all the interned symbols in a struct and passing specifying it as a data pointer when constructing the functions. However, this did not work as the emacs_value objects does not seem to have a lifetime outside of the invocation of a native function. I haven't seen this documented anywhere, so that was a bit surprising at first. The fact that this failed is the reason you see all the calls to env->intern everywhere. Regards, Elias --94eb2c11bf24e3f9be0548189617 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9= February 2017 at 19:55, Joakim Jalap <joakim.jalap@fastmail.com> wrote:

This is really cool :) Just looking over the code quickly it = seems like
it would be useful to extract some of the functions in your module as a
sort of "emacs module lib". I mean things like bind_function, xca= r,
xcdr, lisp_push (which is cons) and so on. Shouldn't everybody who
writes a module want most of these?

Just a thought :)

Thanks! And yes, I ag= ree. This is my first attempt at writing something that uses the module API= , and these are definitely functions that I cannot see anyone writing a mod= ule would not end up reimplementing.

In fact, I= 9;d go as far as suggesting that some of the boilerplate should be provided= by emacs-module itself. In particular, having to do env->intern(env, &q= uot;nil") just to get a reference to nil is a bit crazy.
I tried putting all the interned symbols in a struct and passin= g specifying it as a data pointer when constructing the functions. However,= this did not work as the emacs_value objects does not seem to have a lifet= ime outside of the invocation of a native function. I haven't seen this= documented anywhere, so that was a bit surprising at first. The fact that = this failed is the reason you see all the calls to env->intern everywher= e.

Regards,
Elias=C2=A0
--94eb2c11bf24e3f9be0548189617--