From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 15 Feb 2015 12:08:36 -0600 Message-ID: <85zj8fcajf.fsf@stephe-leake.org> References: <54D85304.1030600@cs.ucla.edu> <54D9AC29.2020603@cs.ucla.edu> <54DA8539.1020905@cs.ucla.edu> <87zj8ktq8f.fsf@lifelogs.com> <54DD6413.1000403@cs.ucla.edu> <83wq3m436s.fsf@gnu.org> <54DDEB4D.5040300@dancol> <83egpt4zz6.fsf@gnu.org> <54DE12E9.5040606@dancol.org> <85twypiiug.fsf@stephe-leake.org> <83zj8g3n16.fsf@gnu.org> <857fvkik49.fsf@stephe-leake.org> <83lhk0wkfl.fsf@gnu.org> <83k2zkwig5.fsf@gnu.org> <85k2zkgg8t.fsf@stephe-leake.org> <54E0A523.9030503@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424023857 18055 80.91.229.3 (15 Feb 2015 18:10:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 18:10:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 15 19:10:45 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 1YN3eV-00036i-P9 for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 19:10:43 +0100 Original-Received: from localhost ([::1]:36172 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN3eU-0003kD-P1 for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 13:10:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN3eL-0003k8-9M for emacs-devel@gnu.org; Sun, 15 Feb 2015 13:10:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN3eG-0003wL-9x for emacs-devel@gnu.org; Sun, 15 Feb 2015 13:10:33 -0500 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:37366) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1YN3eG-0003w8-25 for emacs-devel@gnu.org; Sun, 15 Feb 2015 13:10:28 -0500 Original-Received: (qmail 1441 invoked by uid 0); 15 Feb 2015 18:10:25 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 15 Feb 2015 18:10:25 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id siAK1p00L2UdiVW01iANBs; Sun, 15 Feb 2015 11:10:24 -0700 X-Authority-Analysis: v=2.1 cv=J8Y5smXS c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=TeMFXEv2S7AA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=jrwKn-8xaegA:10 a=0HtSIViG9nkA:10 a=KxCsr730AAAA:8 a=mDV3o1hIAAAA:8 a=G5JqkncIdjHMpTSWCSUA:9 Original-Received: from [70.94.38.149] (port=51752 helo=takver) by host114.hostmonster.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.82) (envelope-from ) id 1YN3e8-0004dH-BG for emacs-devel@gnu.org; Sun, 15 Feb 2015 11:10:20 -0700 In-Reply-To: <54E0A523.9030503@dancol.org> (Daniel Colascione's message of "Sun, 15 Feb 2015 05:54:43 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 70.94.38.149 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.25.95 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:183100 Archived-At: Daniel Colascione writes: > On 02/14/2015 04:39 PM, Stephen Leake wrote: >> Eli Zaretskii writes: >> >>>> Date: Sat, 14 Feb 2015 18:02:22 +0200 >>>> From: Eli Zaretskii >>>> Cc: emacs-devel@gnu.org >>>> >>>>> From: Stephen Leake >>>>> Date: Sat, 14 Feb 2015 09:32:54 -0600 >>>>> >>>>> Emacs ada-mode does indentation in two steps; first it parses the source >>>>> code, and the parser actions are lisp functions that eventually call >>>>> put-text-property to store information about the syntax and/or semantics >>>>> on many identifiers. Then the indentation code uses those text >>>>> properties to compute indentation. >>>>> >>>>> I have a generalized LALR parser implemented in elisp that is fast >>>>> enough for many user's Ada files, but some users have much bigger files, >>>>> and it takes them 10 seconds to parse. So I need a faster >>>>> implementation. So far my benchmarking says I can get close with a >>>>> machine compiled parser. > > You don't a parser in C. You need a smarter parser. Look up > "incremental", please. Yes, an incremental parser would help. I have looked at that; I'd much rather write that in Ada than in lisp. I tried using an Ada parser in a separate process communication via pipes over stdin/stdout; the communications overhead was too much. So a module implementation would still be a good thing. For the moment, just moving the current parser into a module is the first step; if that is not fast enough, implementing an incremental parser is the next step. >>>>> So the module would contain the generalized LALR parser; the actions of >>>>> the parser would still be calls to the lisp functions. > > The right way to let C libraries call Lisp functions is to let C > libraries accept C callback functions, then thunk from C callbacks to > Lisp functions in the CFFI layer. That's what other CFFI implementations > do. This way, your library _still_ doesn't need to know about specific > Lisp internals. > > The module proposal in this thread will harm Emacs development because > it'll put unnecessary constraints on the elisp implementations. Look at > how much trouble PyPy has with CPython modules. It appears that the people actually working on this issue don't have experience with the various forms of module interface. Perhaps you could take a stab at writing a CFFI layer that is sufficient for the curl module? -- -- Stephe