From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 28 Aug 2023 23:08:58 +0800 Message-ID: References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28262"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 28 17:10:20 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qadsi-00077d-Ge for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Aug 2023 17:10:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qadrp-0006MK-GN; Mon, 28 Aug 2023 11:09:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qadrn-0006LW-5q for emacs-devel@gnu.org; Mon, 28 Aug 2023 11:09:23 -0400 Original-Received: from sonic303-21.consmr.mail.ne1.yahoo.com ([66.163.188.147]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qadrk-0003dw-7e for emacs-devel@gnu.org; Mon, 28 Aug 2023 11:09:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693235353; bh=M2I1Im+/JONV3HemJfmPayzFXR/byl4XXHnhOw9tnEQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=exjf3Wh9R6WpWI8Z6mmqZJVE7nSgOxnPDCejlPPfY38Fb0zxVtc+AR7meAI5iTg7Er/AUDdrxDsBOb3x6NG2vLSbaxKlWzbyF8eW4JVhJ6poer4gIGdHGJvR3E6u1GR8vMna8M0elAjZ1L4h9hQ2gTCgB8KfnYEdEUhkRBMQ8njy6CTihhWUTA+FE5vOSiNJJOY1KhH2auQdXBy05rZyz0trBN7zBWDLpuirPey4TdDZyL4aMIA4X7KsLQCrTZowRsciiw8qBx5V6Dtu8/lQaoy6BYzkkJxmm7Qmw4LYELa0BLQLJs64V3HFJJhORK8lPUH/cPQtXd5niCudjmIopg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1693235353; bh=KQH3sk0aGb1mZn/lU5yRx15XxoC7jiEcoxwTzUGcf5U=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Sx8yIRjZYU+Wr5WYGkef+/cPjMmnpCqXwX6rlBbSQcdW3yayrVWjVO9hEDZrwvV16t4YflO0C9qYXQgrkkuIvewqJKbcpmUKgFDtq4jY7y2IErRK86aaWBsHe+4jwH6qQ3xqN6CkgKxdaLMs/iRGmfM28WB358Wa5nx0Yo7WTflobNtUEhYs484XZ+uPZyi2dgJtsU9VIclLWOtw1H443Xf7PtH0SKpSNbXoVDFu7Pm/CkzqSzxu+v6jhtG5FDBUiy11DA85Hs3nkyoCJLUxRAIfk/m1FELc+mS1WZNO2gYjZn8qC5nUSdaZ+vJOegC62lOzLiQ/NsUK58llekUXPw== X-YMail-OSG: 4dESQOkVM1mSw6nqnMCIzDn7Ecq82ryXD6VAD6nyyoBTeGlnWB57Lc1MR1Y3q4d 4zrbXSc4ssPUi5haaqlsciUwTAUaFvP4zzaNNNXTHpYHm9J4xYD81xP09CLhFJ8EY0UReou.8LLB f0NM.Y_g8f9XXPx3KMDCm0LyBlVcH6CFZjmoB8FVp.XDHvtcK8meKlZohYpWU2qnWvBkBYt6vVWT 8PQAheJ.nm.crrAB1HGOWG6nh9cCeboCfP8XF4PI_dKg9pbuDNs1.Qnr5fNJc4hgSm.9fK8dAzSO bATtNO53DCTaA3hXNsy3KDBHP9Wv_821l0WMFlwviG7rA6e7C9eOYoWPdIDUnwaUvp087w2BOEZv MPvFPac8lWjo.kE.hB9esIRMAI512q2aeYLKpfMec_Lf0FLAjbRkUbqvmFKG1HDaY8acgdm6oVRd UkntoHyfpqhEWL6FmZ11JQnN.pGCuruBGRlbVZMVz81ULQIiMUh_JKFwczNlaLkXe8SPHNxXVjYD IC5wg.tXhQ5.WSXVsJorEfr0YpSJjXkICaLXvzTMvex_ScpYCALwV5b8eLbMXOa7bYCDYFsK7FlM _hKtz9sXzoyzVJSsogrIgfdXmIDDdwgDDZSZMz1VEYKZiL27848DkVSl__7JtkqfvNrnb5LRN0Kj N7MCXuIJNZhIDIfg2AQ6blaYtLylSn7d2Jmu28X_PuyJJV5qDo1n4c.4hfkPYJjJ82TVsRnMhf07 iunBfsn99aodwg0RV50bxmwM13JYPLeZKrHDNKV2Iotz25uE3vi0fMuV1ZJKfGmggqcVGlKQM.Sa vgfMT12j1lNTx9fBOhaFv4yp8OurPqsbeHCZDzq0Gk X-Sonic-MF: X-Sonic-ID: f4e109cd-1c08-40cb-9822-172d6930def3 Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Mon, 28 Aug 2023 15:09:13 +0000 Original-Received: by hermes--production-sg3-69654d8bd-gltbk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 94a56e96845dab9085be76caf15b351b; Mon, 28 Aug 2023 15:09:06 +0000 (UTC) In-Reply-To: (Arthur Miller's message of "Mon, 28 Aug 2023 16:08:58 +0200") X-Mailer: WebService/1.1.21763 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.188.147; envelope-from=luangruo@yahoo.com; helo=sonic303-21.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309435 Archived-At: Arthur Miller writes: > Unix which? Unix is not a single program; it is a family of operating > systems, and I am quite sure nobody runs the same kernel they did back > in 1970. I don't know what you are talking about you have > "demonestrated". You said yourself *was* and not *is* which suggest > that those kernels are rewritten in order to support those C programs > that can be interlocked. Again you are constructing yourself things > here: I haven't said it is impossible to write mulththreaded C > application that can use locking. Each extant Unix system today contains gobs of code derived from the Unix kernel developed at BTL in the 1970s. None of their kernels were ever rewritten -- rather, they were subject to iterative refinement that eventually allowed them to operate on SMP systems. > There are many applicaitons that have been redesigned. Emacs has been > redesigned since its first incarnations as TECO editor if I have > understand the history. For the very last time: I haven't said Emacs > *can not be redesigned*, on the contrary, I said Emacs *should be* > redesigned. Emacs core so to say. You are fighting against things I > haven't said; I don't know why, if it is lack of English skill, or > something else, but we are talking constantly beside each other. Perhaps you define the word "rewrite" differently, but its customary meaning implies a reimplementation from square zero. My point is that doing so is a gratuitous and unnecessary gesture, and we would be better served by more realistic assessments and consequently more reasonable proposals. > Are you saying that a non-multihtreaded program written in C can > suddenly become multithreaded without being re-written to support > threading? Nevermind, you are totally, on purpose or lack of > understanding, missing the point: you have to rewrite stuff to make it > multithreaded regardless of the language if you intention is to have > Emacs core multithreaded. Supporting multithreading is not same as > having entire Emacs internals be multithreaded. Since when does interlocking call for a rewrite? > No, it does not because you have missunderstood that I mean something > else. Then clarify what it is, for the plans you present (rewriting Emacs in a different language) sure resemble plans for a complete grounds-up reimplementation. > I propose porting core API to Common Lisp because that would save you > implementing all those things that you need to make Emacs > multithreaded, better GC etc, because it is not a trivial task. At the cost of portability and control? No, thank you. Let me ask a question in turn: how many of the popular and often-cited Common Lisp implementations are as old as Emacs? What guarantee is there of their continued existence 10 or 20 years into the future? > Of course you can re-write all that stuff in C too, nobody is denying > that it is possible. I am saying there is no need to reduplicate the > work, and there are other benefits of having Emacs in Common Lisp. The work to be duplicated is menial and more-or-less already complete. The remaining bulk will need to be tackled irrespective of the language used to implement Emacs. The conclusion as to whether we should overcome that bulk as-is, of if we should compound it with the challenge of rewriting Emacs in a new language, is left as an exercise to the reader. > Look harder. Any examples? >>> Well yes, C is portable and fast, nobody denies that. So are some >>> CL >>> compilers. >> >> Which Common Lisp compiler is capable of linking with Java code >> through >> the JNI? (ABCL doesn't work, as the Android JVM can't interpret the >> bytecode it generates.) > > I don't know what you are trying to say; that sound like very > uninformed statement based on missunderstanding. Calling Java via > native API and generating bytecode that runs Lisp on top of Java as > ABCL does are two completely different and separate things. I am quite > sure Emacs does not generate Java byte code. But I don't see how is it > even relevant, I haven't suggested to run Emacs on JVM. Perhaps it is > possible who know, but I have suggested to use sbcl which is a native > compiler specialized for compiling Lisp (and runs on Android as well). It's not possible to load a Common Lisp image into the JVM, because the Java linker is only capable of linking compiled C objects that export C symbols. Therefore, SBCL cannot run within any GUI Android program, given that they must be started from Java. > "only" ? :-) I can asure you that Lispers have access to both kernel > and user space threads. Search on Bordeaux threads. That's only a wrapper library for the incoherent threading primitives furnished by different Common Lisp implementations. >> garbage collection strategies vary between machine types. I'm sure >> we > > Does it? Yes it does. > I am also sure everything is possible, it is software, as a wise old > grey head once said. It is just how much effort and resource you are > pouring into it. SBCL runs on basically all important platforms on > which Emacs runs, minus as mentioned DOS and Windows95; I don't know > if there is some other. But it is not the point. The point is: there > is another community working on the same problems you have or wish to > solve. And they have come far away than you. You could re-use their > work, and if you miss somethign add those missing parts so everyone > would benefit, or you can live in an isolated island and do everything > yourself. C is hardly an "isolated island". Anyway, we need a portable, fast, flexible and ubiquitous language, and Common Lisp doesn't fit the bill: if a platform as anodyne as Android poses problems for it, what about the next sandboxing contraption for Unix systems? Or any future system whose appearance down the line we cannot anticipate now? What if our requirements outgrow Common Lisp's capabilities? > I am telling you that sbcl/ccl has already solved those problems you > have to solve in order to have multithreading without having to lift > your lock. We have too. What we have not, they cannot offer either. >> Instead of denigrating the C language, Emacs's C core, and so many >> other >> components critical to Emacs that have been subject to unjustified >> invective in recent times, why not direct your attention to a more > > I don't think I understand how I "denigrate the C language" and what > "unjustify invective" in this case is, but I don't think it > matters. Once you also said I should be forbidden to talk about Emacs. It does, because such motives drive people to engage in many hours of time wasting wild goose chases, all to ascertain which language Providence meant for Emacs to be written in. >> direct your attention to a more >> productive task, such as identifying the complex interdependencies >> between different pieces of Emacs's global state to establish a >> detailed >> plan for their interlocking? For this task, the most important tool >> is >> a control-flow visualizer such as cflow, and an ample supply of >> paper. > > Can we save nature and our selves? Parse error, sorry. > Nor are you sole Emacs devs, aren't you? I don't think calling names > is appropriate, so I want, but I can come up with at least four people > who work on Emacs and who are experienced Lispers. How active they are > in development recently I don't know, I don't follow the list every > day as I am used to, but I certainly haven't targeted Eli nor you with > that one. Names? Would they be willing to take responsibility for the areas which we oversee, in the event a Common Lisp Emacs comes to pass?