From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 28 Aug 2023 16:08:58 +0200 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="8765"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 28 18:12:34 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 1qaeqs-0001sj-4t for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Aug 2023 18:12:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaepj-0008Hr-Mv; Mon, 28 Aug 2023 12:11:19 -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 1qacvT-0000B5-6u for emacs-devel@gnu.org; Mon, 28 Aug 2023 10:09:07 -0400 Original-Received: from mail-he1eur01olkn2051.outbound.protection.outlook.com ([40.92.65.51] helo=EUR01-HE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qacvP-0007g2-Ip for emacs-devel@gnu.org; Mon, 28 Aug 2023 10:09:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=idRQuoGsAclvPlqED4hiWmZFuYdfbpRb1vVRR9UQpCjlIJ52+BYsdfTNE7CNGgKbKlaa9hbBn7/aaNsxXiiNJWDydQh1oJG9S2DUJ0nRHfpDWk4RIQGyVWEA1cAcEeRKeRuV0lP70bqPGSeZ/qcCJQwrCkcKLZ6FgwCbY7aL75HBAdsKRLEkSj1RJM+pQxuraBA4cfUyVgJlkV89f/VqayTgwgpZkxgH+WvVxtozjTL1U1MgixHR8gdQeqD9+KHQI4C/HYlvGhcwwjVUCZPpAbr5tGfuwNRtV4+e+fmIzV1U5xT4LdrtA36T3sxVbdXTF4ZqLoVKsu3HgTqa+FIG7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8j0OxxSubDKAqY4SgZKwbE+icui9Moiz3ysV70kVNIk=; b=L8Dfc54EgDFGseLIPosaONnFWw+88dVMMlA79vQDpc0Sjn9MhpwnHhmW17rqhhiHSowkoa661j+4bslMunahDklgvMKFmxp3++cftLfjSCfhc70fhfiHRR4kxa4T02447jWqX+0LFna90KGbZBWHFWGiFMbKdC3G3nZGDtNa6qWARKRpzePTpJdtwB/YVaoeZmXHEmcpoat1OzhycsoiZf7UhvSuSOflN40HiFfPCxAN28qIPOAB+/TMgnx9oaSH9TXFeT9bCH2Zfhn1E2eNU477dY3kfWjQJPtXUBY34+xcGgCdWVrua7ph9kaOhZEpsk/gXage+KW8Jg3byZeybw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8j0OxxSubDKAqY4SgZKwbE+icui9Moiz3ysV70kVNIk=; b=bToYZAKfCS9sGoCrLywx42pa+KniR/edWf/Z57dzIhJRlTtyO341RxJtGoPs6zYH1hrvJWNcvT/C/xJC3SUj6V8OQsf42OrG3ce0Z8N71bw5omUqqgsgiv8JRhjnNcDq23xvr8x0UiTPknla4UzDd4EbylMH6PtCg+Qew3sVhSHx/xPG9kyTOvFtZVtPVHr2MeGNnRTa1NNtk1ny8FmRdy28EmX3tB03KYC7wYdaWqDnLUWjCnSTp61IabaMl1Gqhwve1gVl3QUb/65sqpVAToxlIiETw7W+jg2J8GbqQFeNPi4sHOt6Yi6LiORsdYmAdwmdWoIqfuVJ4tUbsqeR7w== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM9PR09MB4657.eurprd09.prod.outlook.com (2603:10a6:20b:2dd::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.34; Mon, 28 Aug 2023 14:09:00 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::df56:b1b1:64b1:6122%7]) with mapi id 15.20.6699.034; Mon, 28 Aug 2023 14:09:00 +0000 In-Reply-To: <873503y66i.fsf@yahoo.com> (Po Lu's message of "Mon, 28 Aug 2023 15:31:01 +0800") X-TMN: [rhmAuBZDx9awzdK6a/yUU2IG+6uoh2NgUsUpoyBJvGE=] X-ClientProxiedBy: MM0P280CA0071.SWEP280.PROD.OUTLOOK.COM (2603:10a6:190:8::25) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <871qfnp8cl.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|AM9PR09MB4657:EE_ X-MS-Office365-Filtering-Correlation-Id: fc066577-5694-4b5e-651d-08dba7d0538a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: l3edPaLkB5NW8665TATZrOUqYGFQq5P5IYS8IFxIxWCI2hrviCaQdsmTnB9JH65eEV14YF+V0d3KLnaI/KT86Qz3j5oVhoJCTZtdWEnJuofSngCk3ZCm7BA2J7XQcKm83H2rJ4VbX2+m4CjvE8AqDAZSqFK3xxZTNfZnNlgsfi946NssoTWAI1ZVn7IMEDqP3Wz/QpKoPagwvaoKnEejM6Q9V6X13N7N061nPuLHpZmH6l+PYX/FvHwhTP+v3G2SdWW7KWNNr9hCu7pkeNI0G5d7Owf9WLjD0iqxJRPWgH23AoTvaNCDdYeP2QiilulyWT/2DRIpxg7+7VIehohJUe2BNJVKP3nni63QUwGemmegRcWS6cqI2KnwykDooqExx1lOXgx36Xt/gjf6sjH9H10CZnIn9NZtR6yTGzaN6Pwrk795/R+Oay5gQHoAPERhot01m/1Cg9AQp2+oWrFdRSxx3b+3apAXkd3HPmZ9a3vwwn1tOhRC4YJYhs/X17OH7EKLsyoa3Z7aw5LM2qShOTaqG7hzsFfczVCwIOJRAVNl4VzoRNMOx3jHGXOMKUa1 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?2wr+3hSzV7sNWMYXcySQQrMcyHN0c6zybBD5cPiuT28dRsSDSq6ym03JBlEb?= =?us-ascii?Q?lLdUFVv1g0dCEie2vPBUq0BWBMw0LicSHfK0q9XVMJW9vKWHnICLPMmUXN8r?= =?us-ascii?Q?4zSV02ska5cFId8wfFV07i0TAVKfLWqU4MyeE9LmaSUMgOeWyWWNXElYOExz?= =?us-ascii?Q?7UGWOvCXMgpAM59bE9LGQxO7FHyzCrr349/6BjwJ2MqBtPgKi9ZBphEtjfSP?= =?us-ascii?Q?/6YDwbrvbwxeZX5hgwYqkwNnObKul9aj2GYJ15yywY1qmZFQiht3VrAimENc?= =?us-ascii?Q?nLA+9OhcpJ9SlPI++Eef+QlVDwXYxuVzGXft0p4cKR9Yiev97jnP+7/4mQ3k?= =?us-ascii?Q?Kl+/ciI2pgcipSOTO6py6GCDDt0FLMSZCyzcSgMjSC6AuO0lR0RuJylHfved?= =?us-ascii?Q?7hX2OxerjPWZUcLZfTMtzZLqdkqGeBXsRdzsNuto+nqZpu6/gZdF0Q4gGkKw?= =?us-ascii?Q?pVVQbUZdDKyoHRMXbaG41c3hXxJEj8hkQS04o+IJJF/jSW53oGjsnVVud4M4?= =?us-ascii?Q?yzFflylNtUb5+ARyHpZYyWZX2eTGAjycFgevQCVP/fpvtSQ4hm3qnUxqPtfa?= =?us-ascii?Q?7+6u/XwXRTnmJ/pp3YSd0+6Na6g3J0tLPO2KsdIR88aQi53cEVZcwKm2Cprc?= =?us-ascii?Q?k9 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: fc066577-5694-4b5e-651d-08dba7d0538a X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Aug 2023 14:09:00.6957 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR09MB4657 Received-SPF: pass client-ip=40.92.65.51; envelope-from=arthur.miller@live.com; helo=EUR01-HE1-obe.outbound.protection.outlook.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_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 28 Aug 2023 12:11:16 -0400 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:309444 Archived-At: Po Lu writes: > Arthur Miller writes: > >> I think you have missunderstand what I mean; I can try make it clear >> that I mean parts that considers Emacs core, shared state and so on. > > That's what I was referring to, yes. > >> You are missing the point: I wasn't talking about *who* changed the >> Unix; the point here is that it got *changed*. > > My point is, Unix has demonstrated many times over that programs written > in C can be interlocked, and doing so is more productive than a rewrite. 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. 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. > in C can be interlocked, and doing so is more productive than a rewrite. 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. >> None. And nobody has suggested that such issues exists either, it is your >> construction. On contrary, I am saying that Emacs should undergo such >> transformation :). > > That contradicts your assertions below, where you propose returning to No, it does not because you have missunderstood that I mean something else. > the drawing board to produce an Emacs written in Common Lisp. Curiously 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. 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. > enough, I can't locate any precedent for large and complex Common Lisp > programs being modified for multi-processor operation. Look harder. >> True. MS-DOS and Windows 95 would have to go away. Perhaps some other >> popular OS from 1980s-1990s? > > They wouldn't have to go away if Emacs remains written in C. Tough argument indeed. It is certainly very importnat to keep the development back to support two ancient non-free OS:s. >> 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). >> Nobody said it is "panaceas". But sbcl would provide a better lisp >> machine, in terms of garbagecollector, threading etc; something you will >> have to develop for Emacs eventually. You heard that one about a guy >> with name Isaac Newton and standing on shoulders of others? :) > > SBCL only supports kernel-based threads on a handful of systems, and its "only" ? :-) I can asure you that Lispers have access to both kernel and user space threads. Search on Bordeaux threads. > garbage collection strategies vary between machine types. I'm sure we Does it? > would be capable of supporting more while remaining portable, and Common > Lisp leaves much to be desired as a pair of shoulders to stand on. 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. >> Just reimplementing the C core would not, because you wouldn't use >> multiple threads. But if you would like to thread Emacs command loop or >> internals itself, than you would have to reimplement it that way of >> course. Think of Java Swing; at least 20 years ago when I war >> programming Java, it was not thread safe, but worker threads were OK. > > You're okay with Emacs crashing if threads, wielded incorrectly, trample > over internal state? If so, the global lock could be lifted from Emacs > Lisp in under a week. 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. > 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. > 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? >> I am sure present maintainers are well versed with CL, just not very >> interested to rewrite Emacs in CL; and I wouldn't expected them to be >> either :-). > > Two data points: I'm not an adept Common Lisp programmer, nor is Eli. > I'm not even an Emacs Lisp programmer by vocation. 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.