From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: More (de)compress? Date: Mon, 19 Aug 2013 19:13:19 +0300 Message-ID: <83d2p9lkv4.fsf@gnu.org> References: <52120CEA.6060701@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1376928781 9003 80.91.229.3 (19 Aug 2013 16:13:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Aug 2013 16:13:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 19 18:13:02 2013 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 1VBS4i-00015C-GX for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2013 18:13:00 +0200 Original-Received: from localhost ([::1]:43972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBS4h-0008RO-V2 for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2013 12:12:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBS4Z-0008Id-Dj for emacs-devel@gnu.org; Mon, 19 Aug 2013 12:12:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBS4O-0002Wf-Vb for emacs-devel@gnu.org; Mon, 19 Aug 2013 12:12:51 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:56612) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBS4O-0002W5-OQ for emacs-devel@gnu.org; Mon, 19 Aug 2013 12:12:40 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MRS00500CJT7K00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Mon, 19 Aug 2013 19:12:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRS005CKD1208A0@a-mtaout22.012.net.il>; Mon, 19 Aug 2013 19:12:39 +0300 (IDT) In-reply-to: <52120CEA.6060701@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:162879 Archived-At: > Date: Mon, 19 Aug 2013 16:17:46 +0400 > From: Dmitry Antipov > > Inspired by current decompress.c, I would like to propose the symmetric > compress function(s) as well as support for more compression methods. > This is what I have now, and basically it works; still needs MS-Windows > support, better error detection and a few other things. What kind of Windows support do you think is needed? Are you thinking about dynamic loading (which is a nice-to-have feature), or about something else? > + ### mingw32 doesn't use -lbz2, since it loads the library dynamically. > + if test "${opsys}" = "mingw32"; then > + LIBBZ2= > + fi This will only work if you implement dynamic loading for libbz2. Otherwise, Emacs will fail to link, because you call libbz2 functions, but don't us -lbz2 on the link command line. > + ### mingw32 doesn't use -llzma, since it loads the library dynamically. > + if test "${opsys}" = "mingw32"; then > + LIBLZMA= > + fi Likewise. > - profiler.o decompress.o \ > + profiler.o decompress.o compress.o \ Why do we need both decompress.c and compress.c? The latter covers the same ground as the former, no? More generally, if this is a real submission (as opposed to just a POC), then I really don't understand where is this going. E.g., do you intend to use these primitives, when they are available, in preference to jka-compr? If so, why aren't there changes to that package as part of the changeset? Likewise for info.el, where it uses external programs to decompress compressed Info files. If you do not intend to bypass jka-compr etc., then I must ask what are the use cases for these primitives, and whether they are different from those of jka-compr?