From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Why not zlib-compress-region? Date: Sun, 29 Jun 2014 01:30:51 +0900 Message-ID: <87fvipvvwk.fsf@uwakimon.sk.tsukuba.ac.jp> References: <53AC0D17.9020604@yandex.ru> <53AD8EA8.9090805@yandex.ru> <83egy97cj6.fsf@gnu.org> <87k381w61p.fsf@uwakimon.sk.tsukuba.ac.jp> <83a98x6up5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1403973090 409 80.91.229.3 (28 Jun 2014 16:31:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Jun 2014 16:31:30 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, dmantipov@yandex.ru, emacs-devel@gnu.org, sdl.web@gmail.com, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 28 18:31:24 2014 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 1X0vX6-0004co-2Q for ged-emacs-devel@m.gmane.org; Sat, 28 Jun 2014 18:31:20 +0200 Original-Received: from localhost ([::1]:55282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0vX5-0006nQ-NB for ged-emacs-devel@m.gmane.org; Sat, 28 Jun 2014 12:31:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0vWw-0006mS-0h for emacs-devel@gnu.org; Sat, 28 Jun 2014 12:31:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0vWo-0001HM-Fo for emacs-devel@gnu.org; Sat, 28 Jun 2014 12:31:09 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:57992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0vWf-0001Fa-S7; Sat, 28 Jun 2014 12:30:54 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 959913FA0AF5; Sun, 29 Jun 2014 01:30:51 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 818EB1A3D4E; Sun, 29 Jun 2014 01:30:51 +0900 (JST) In-Reply-To: <83a98x6up5.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 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:172800 Archived-At: Eli Zaretskii writes: > I know about the package managers, I just wanted to make a point that > AFAIU end-user Posix systems might well lack a compiler. AFAIR, on > non-free Posix systems, installing a compiler actually costs money. Not on Mac OS X. And how many important non-free POSIX systems aren't supported by GCC (not to mention The-Compiler-Suite-That-Shall-Not-Be- Mentioned-On-GNU-Channels)? The real problem for those is more likely whether there is an enterprise requirement for vetting all installed software. > So having an FFI implementation that requires a compiler might be a > disadvantage on Posix systems as well. Anything's possible. I don't think it's worth worrying about it. XEmacs/SXEmacs have *never* received complaints about availability of compilers for our version of "Stefan-style FFI". It's always "ooh, yuck, no GUI installer??!! I can't do that!" or "why can't you distribute binaries in the prebuilt packages?", not a "I have to install a compiler" problem. FFI implementations that *don't* require compilers have their problems, too, since Lisp types sometimes map to different C types for different libraries, which requires a lot of fiddly low-level knowledge on the part of the Lisp programmers that (if they stick to pure Lisp) they just don't need at all. FFI == crashable Lisp. > > usually without going through DLL hell > > (This is unrelated.) I don't believe in package managers as a > means to avoid the "DLL hell". Dependencies are written by people, > which are prone to errors, and having several libFOO.so versions on > the same system, even if their names don't conflict, is not fun. I have a bunch of them (three versions of GTK, two of libpng for example). I don't notice it at all, the PMS installs the right dependencies for everything. (Not to mention simultaneous installs of 32- and 64-bit versions of many libraries.) OTOH, I only have one instance of each version level (modulo the 32-bit issue), because the distros provide extremely good coverage and generally do a good job of sorting incompatibilities (occasionally in the opposite way from my preference, but them's the breaks). So the real point is not the PMS's dependency database, but rather than fact that each distro has a (more or less) canonical compiler suite, and you just install that and it pulls everything else in. > We are talking about the compiler and Binutils. Building those, > especially the former, is not for the faint at heart, not even on a > Posix host. Nonsense. I do it about once a month, sometimes twice a week (automatically via Gentoo's Portage PMS, which always builds from source). Unlike, say, Boost or KDE's nepomuk (which are always holding up the upgrade), I can't remember well the last time a GCC (or TCSTSNBMOGC, see above) build failed on me (except for out of space errors), and binutils failure is even more rare. It might be harder for non-free POSIX systems, and then it might not. Many have open-source repositories with PMSes of some sort. > > I've given up more times than I can count (temporarily of course, > > when I've got a wekk of evenings free I get back to it) on putting > > together Windows dev environments, though. > > It's not that hard, actually, especially if there's no need to run the > configure scripts (as I'd imagine will happen when Emacs supports some > kind of FFI). No, it probably isn't, but since I do it less than once a year, and once done, I use it once then forget it, it induces fear and loathing. :-)