From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 29 Nov 2016 21:59:23 +0200 Message-ID: <83y402qcpw.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480449703 30126 195.159.176.226 (29 Nov 2016 20:01:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 20:01:43 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 21:01:39 2016 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 1cBoar-0006Vf-UI for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 21:01:34 +0100 Original-Received: from localhost ([::1]:39070 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBoav-00014j-Nw for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 15:01:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBoZG-0000QF-Tt for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:59:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBoZC-0001aO-5f for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:59:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBoZC-0001aG-2V; Tue, 29 Nov 2016 14:59:50 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1217 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cBoZ1-0000TA-Iw; Tue, 29 Nov 2016 14:59:43 -0500 In-reply-to: (message from Daniel Colascione on Tue, 29 Nov 2016 11:03:35 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209760 Archived-At: > From: Daniel Colascione > Cc: rms@gnu.org, emacs-devel@gnu.org > Date: Tue, 29 Nov 2016 11:03:35 -0800 > > > Easier: yes. Easy enough: no, not IMO. Not for most of the Emacs > > contributors we have and will have in the near future. > > Who do you imagine maintaining Emacs? CS 101 students? Just look around, they are all here. > We have to assume a certain baseline level of skill on the part of > our future colleagues. I don't want to dumb down our implementation > for the sake of people we don't know and who, for all we know, may > never actually appear. You are insulting most of the people on this list, some of them long-time and fruitful contributors. They don't deserve that. > > The number of people aboard who can matter-of-factly hack the Emacs > > internals on the C level is consistently going down, and is already so > > small they can be counted on one hand. We must make Emacs depend less > > on people from this small and diminishing group, if we want the > > development pace increased or even kept at its current level. > > I've discussed before why I think this argument is ill-founded. We > already have examples over the past few years of people who've > familiarized themselves with Emacs internals in order to add a feature > they want. If there's a need, people will familiarize themselves with > the editor. I don't think this is accurate, but even if it is, it is better not to have this bar. > Please, present some evidence that the reason we've seen a decline in > core contributions due to the complexity of the current codebase. I > don't agree that we'd see more contributors appear if we simplified our > algorithms. You are missing the point: not complexity and algorithms are the problem, the implementation language is the problem. > I agree that what *can* be done in Lisp should be done in Lisp. We're > talking about a facility that doesn't fall under this general > guideline. ??? loadup.el is Lisp code. > >> On top of that, adding Lisp objects will now require > >> > writing its dumper back-end, so this will be a constant maintenance > >> > burden of the kind that only a few of us can bear. > >> > >> Yes, but how often do we make such changes? Once every few years, > >> I think. > > > > More like once a year, maybe more. > > Like what? The last two new types in core have been finalizers and the > module thing, both of which have been trivial Lisp_Misc types. Trivial to some, much less trivial to others. > By the way: it's very easy to add support for new object types > to pdumper. Have you read the code? Yes, I have read the code. It's easy for you to add new object types, because you wrote that code, debugged it, and didn't yet have time to forget how it works. It is also easy for me to tweak bidi.c to add features required by Unicode 6.3 and 8.0. Does that mean anyone else can "easily" do that? > If you want to pursue this path, how about moving redisplay to Lisp? You > know more about redisplay than anyone else around, I think, and > redisplay is a much hairier blob of C code than the portable dumper is. If you stop arguing with me so much about each and every issue, then perhaps I will have time to explore this. As things are, sorry: arguing with you takes up all of my free time -- or what's left of it after triaging and fixing bugs, helping people to implement stuff in C, something you think is "easy" for everyone past CS101, adding and fixing documentation, including that one Daniel Colascione failed to write, and whatnot else that is evidently part of the job. > >> I think this has its own difficulty -- the need to represent everything > >> in Lisp syntax. > > > > I don't think I follow: what we preload in loadup already has Lisp > > syntax. > > Yes, but the data structures that we create via loadup don't all have > easy-to-digest Lisp representations, and creating them is on the same > level of complexity as the portable dumper. But it already works. > *This* code exists. Where is the hypothetical sufficiently-fast lread? In the works, I hope. It is my job as a maintainer to encourage that development. > > First, the only piece of code in the concurrency patch that is not > > entirely trivial is a 60-line function (30% of whose line count is > > comments and ifdef's). > > You're the only person I've ever seen use words like "entirely trivial" > to describe the addition of shared-memory concurrency to a legacy > single-threaded system. Even if the code for the threads system looks > simple, the concepts involved are anything but. Concurrency in Emacs is for people who already know what that is and are familiar with the concepts. _After_ you are familiar with the concepts, the code is surprisingly simple and straightforward. > By contrast, the portable dumper is about marshalling, which I think is > comparatively simpler. The concepts are simpler, but the implementation is not so simple. And some stuff is done manually, with the PDUMPER_* macros rules for whose use are only clear to someone who knows a lot about the involved objects and their use patterns. > The portable dumper is also optional: you can always use the legacy > unexec code, which isn't going away, or just rely on loadup (and the > hypothetical ultra-fast lread we've discussed). If that is the direction we want to move, then the efforts invested in the development of the portable dumper are a complete waste of our resources.