From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: advice needed for multi-threading patch Date: Thu, 27 Aug 2009 02:39:13 -0400 Message-ID: <24F68B6C-96CD-4360-86E2-B0B2597B1633@raeburn.org> References: <5C8D2D84-C4B5-47A2-8392-370D7C3651CF@raeburn.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1251355438 13620 80.91.229.12 (27 Aug 2009 06:43:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2009 06:43:58 +0000 (UTC) Cc: Tom Tromey , Emacs development discussions To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 27 08:43:50 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MgYi5-0000lm-Ig for ged-emacs-devel@m.gmane.org; Thu, 27 Aug 2009 08:43:50 +0200 Original-Received: from localhost ([127.0.0.1]:53371 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgYi5-0003uk-1h for ged-emacs-devel@m.gmane.org; Thu, 27 Aug 2009 02:43:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgYhE-0003IP-Tw for emacs-devel@gnu.org; Thu, 27 Aug 2009 02:42:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgYh7-0003De-Q2 for emacs-devel@gnu.org; Thu, 27 Aug 2009 02:42:53 -0400 Original-Received: from [199.232.76.173] (port=56135 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgYh7-0003DZ-Fh for emacs-devel@gnu.org; Thu, 27 Aug 2009 02:42:49 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:38086 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MgYdf-0001o1-6s; Thu, 27 Aug 2009 02:39:23 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n7R6dDdv021177; Thu, 27 Aug 2009 02:39:13 -0400 (EDT) In-Reply-To: X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114672 Archived-At: On Aug 27, 2009, at 01:07, Miles Bader wrote: > Ken Raeburn writes: >> in part, to replace the most fundamental layer -- representation, >> allocation and GC -- with Guile. > > Do we actually want to do this? How is guile regarded these days > (back > in the day, it was a horrid bloated mess)? I still think of this project partly as being in the "let's see how it works out and decide if we want to keep it" stage, or even "let's try this big application and see what problems we find in Guile". So I'm not quite ready to answer -- or ask -- if we want to do it. With a bit more polish, and some more intense testing, and performance analysis, maybe... I can't really speak to how Guile is regarded; I do much more stuff in the Emacs and Guile internals than with ordinary applications that might use it, and I'm by no stretch of the imagination any kind of Scheme expert. But I don't think how Guile is regarded should be as important as how Guile *is*. If there are real problems with using it in Emacs -- as opposed to everyone just remembering how it *used* to be considered a "horrid bloated mess" -- then we can try to fix them on the Guile side, or decide to drop the project. It's had performance problems for some time, but recent work has made some big improvements, putting it back in competition with some of the other implementations, and there's a bit of talk about compiling not just to VM byte codes but even to native code for some architectures someday. It sounds a bit like pie-in-the-sky stuff, and some of these sorts of things have moved very slowly in Guile development in the past, but the guy doing the compiler and optimizer work right now is making some good progress, and I wouldn't put it past him. There's also some GC system work happening, but I haven't been following that closely. And if we wind up in a situation where doing such work benefits both Guile and Emacs because one is using the code from the other, it *could* be good for both projects. (And, of course, if it goes badly, it could make it harder to improve things all around.) Thread support is another example -- if Emacs were already using Guile underneath the Lisp engine, thread support would probably be quite a bit easier. My reasoning for trying this is in some ways political as well as technical. Guile is touted as the GNU project's extension language. Yet one of the highest-profile, most-extensible and most-extended programs GNU ships doesn't use it, but instead uses a separate, private implementation of a rather similar language. If "GNU's extension language" isn't good enough for this application, and can't be made good enough, then maybe we should declare it a failure as "GNU's extension language" and either do something else or drop the idea entirely. But I don't think we've gotten to that point. And on the technical side, I'm trying to keep most of the work in the Emacs "application-level" code non-specific to Guile, so if someone decides to replace the Lisp engine with something other than Guile, my changes to isolate the implementation details and assumptions made may still not be wasted. BTW, if anyone is interested in helping on the Guile-Emacs work, I'd love to have some help. There's quite a number of pieces still to be tackled, some purely on the Emacs side, others having to do with making the interaction between the two work better.... Ken