From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.text.pandoc/25097 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: brainchild Newsgroups: gmane.text.pandoc Subject: Re: build customizability Date: Sun, 3 May 2020 23:45:09 -0700 (PDT) Message-ID: References: <43e8ce91-0738-4477-bcf5-e826219d9b1d@googlegroups.com> Reply-To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_306_52846467.1588574709427" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="32671"; mail-complaints-to="usenet@ciao.gmane.io" To: pandoc-discuss Original-X-From: pandoc-discuss+bncBCK6XHV3WYGBB5XTX32QKGQERHG3RGA-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mon May 04 08:45:13 2020 Return-path: Envelope-to: gtp-pandoc-discuss@m.gmane-mx.org Original-Received: from mail-oi1-f191.google.com ([209.85.167.191]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jVUqn-0008NE-Nc for gtp-pandoc-discuss@m.gmane-mx.org; Mon, 04 May 2020 08:45:13 +0200 Original-Received: by mail-oi1-f191.google.com with SMTP id b203sf5164161oii.3 for ; Sun, 03 May 2020 23:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=pRgBHqhxJJjUaj+eyrVG/t6bZ+FHbjtlwdUUqMfjYDM=; b=ksXqYRY0SktQIY8FNfB9zSNdC1aLzR271p7ybaCkoBKo89IiT//cs3RYmhbxpmzF5R +0UyC90XmKAEmuzxI3uoEXGUwwKApGZUPcf0lkZG+canD+Y2WGCPRELaiOByblIGd5dR xQ0cAmqUxCAM5noGt1GJVbTyGbuFAjE873BB45dWgVk8THYB9nsLL3m4WeCugAf7YXzK fEuqE0BUZpZsUIUuj4R8q1AX7qZwlcD7MMHQMtXx68ti6iZmPP8n0I3ZQDAoI/nc9R4S 5SJw+N2gNtnQEls1srWLwFA2JijmXmnjvwGv4hVL9Eoon5jspFN1jmDkyrJWDeS2NCpu u5lg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=pRgBHqhxJJjUaj+eyrVG/t6bZ+FHbjtlwdUUqMfjYDM=; b=J8q/80jiBtUGUtnZm0QygG4joUJiDpeoCJtgG5rn5OMfwCJpLLXtzEIdLVwvYwjWk3 NM+tcO4BK26dwoe95nCOO6uWxWOVahgPnwEBGzHqaWJJKGtJ7EoFnAZtjD6X2By00pR8 dAGR1fnyA9inQGHzn4+ZIGNHox9oa3VWqERHJe0dh9AxUx4HMY792eeAdo1sW1DNW8Ka WZFX5c9kcthumUDqU/60MdTHt+qgQDRffH8rxqxqkhoo64SN2Dsb8Qi9hVWSm1lRDdQB zC8vuTMAWN8MNmi+t7OiMbXdWu8C++JgebFyB5N08r1fzwe20Meo/BTIzQ5ae/oJoEvc W2jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:date:from:to:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=pRgBHqhxJJjUaj+eyrVG/t6bZ+FHbjtlwdUUqMfjYDM=; b=i9HvemPhKoOFc3iNLzTbOgBIUPKP3lp9Gi4gtxPwbN4Diem4dXpASjJk99HoiRC4ZI 4BwnSVKbkEZjJPwxJAfqOSzhNMrZC0GBcU2RKJPjerji22I9/lTJxIZ9Yj9kKf+371IV TFMwiwp3PADjpKTACYZ7iLcpfVyZJ0yFXwx4ojHFOC0MB+nWdCJEn/WergXqgJhdmaOs gTEDWuPD2RJcYb+Le0U0U80MKYM8moKfXabLKb7pIA1z+yWOGh7fEieFafbDXwlp0ltD cxfrQoyq0yIKPxGZ+95S+A31G0UhA0O2GXD4g6DoR1mYWqnpENTq1VunuDX2SODqvcck cGVQ== Original-Sender: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org X-Gm-Message-State: AGi0Pub3Fq8Zo7EIHjOd3hKquQyhxhxpcnYe+KkfX+pu0D6HPePSnqJH wrADM+qLd4lYnzwedcrR/e4= X-Google-Smtp-Source: APiQypLr4vWK0+l4BA4dwdamf6ogGweddKOoUclAhC5AqLs90IsYdlYHCGV+Uro/SvQg25dwvNWD3A== X-Received: by 2002:aca:3106:: with SMTP id x6mr7649475oix.94.1588574712740; Sun, 03 May 2020 23:45:12 -0700 (PDT) X-BeenThere: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Original-Received: by 2002:a9d:467:: with SMTP id 94ls2346858otc.11.gmail; Sun, 03 May 2020 23:45:10 -0700 (PDT) X-Received: by 2002:a9d:136:: with SMTP id 51mr11934002otu.331.1588574710094; Sun, 03 May 2020 23:45:10 -0700 (PDT) In-Reply-To: <43e8ce91-0738-4477-bcf5-e826219d9b1d-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> X-Original-Sender: ericlevy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Precedence: list Mailing-list: list pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org; contact pandoc-discuss+owners-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-ID: X-Google-Group-Id: 1007024079513 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Xref: news.gmane.io gmane.text.pandoc:25097 Archived-At: ------=_Part_306_52846467.1588574709427 Content-Type: multipart/alternative; boundary="----=_Part_307_620266579.1588574709427" ------=_Part_307_620266579.1588574709427 Content-Type: text/plain; charset="UTF-8" Thank you for the recent comments. Let me respond to all in one message, as they overlap in scope. I address a few issues, in sequence, as follows: 1. *Markdown reader dependencies: *I now understand the conflict. In many potential deployment scenarios, for example applications that employ Markdown source, the embedding of snippets in some target language is unlikely to be needed, except perhaps as narrowly allowed for equations. Thus, if this functionality were entirely enclosed in extensions, and if those extensions could be disabled in the build, then in principle it may be possible to realize the benefit of removing the dependencies on the parsers. I understand that it would require restructuring the code. 2. *Evaluating size of library dependencies: *If, as Albert says, only a handful of packages may be eliminated from the build, even in the case that only a few readers or writers were needed, and if the size of these packages is not vastly greater than the size of others, then clearly the material benefit of eliminating certain readers and writers from the build is very limited. However, I make a few notes: 1. Is the reason that most dependencies would remain even after removing most of the readers and writers that these dependencies are needed separately by all the readers and writers, or rather that they are needed by the core application? In the latter case, perhaps some of the core functionality not needed in basic uses, again at least in principle, can be separated. 2. My earlier question directed mostly at the difficulty of determining confidently the complete set of dependencies to remove, without invoking a formal solution such as graph traversal, compared to the possibility of missing a set in an informal assessment. 3. *Footprint of Runtime System:* No, I was not specifically aware of the size of the Runtime System. I am having difficulty finding a clear indication of how much size it adds to the final executable size, but estimates that seem to recur are in the 10-15 megabyte range. If these estimates are accurate, then it would be impossible to achieve vastly smaller sizes, obviously, but this information alone is not sufficient to conclude the impossibility of achieving significant savings through methods already discussed. Also, I am seeing some hints that a GHC backend for LLVM is available that makes possible much more optimal build results. Unfortunately, I have not found any quantitative assessment of these savings, nor can I find any active project maintaining this interface. -- You received this message because you are subscribed to the Google Groups "pandoc-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/f9fd9cfe-e03f-45d3-bcb5-07267c28e565%40googlegroups.com. ------=_Part_307_620266579.1588574709427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the recent comments. Let me respond to = all in one message, as they overlap in scope.

I ad= dress a few issues, in sequence, as follows:
    <= li>Markdown reader dependencies: I now understand the conflict. In m= any potential deployment scenarios, for example applications that employ Ma= rkdown source, the embedding of snippets in some target language is unlikel= y to be needed, except perhaps as narrowly allowed for equations. Thus, if = this functionality were entirely enclosed in extensions, and if those exten= sions could be disabled in the build, then in principle it may be possible = to realize the benefit of removing the dependencies on the parsers. I under= stand that it would require restructuring the code.
  1. Evaluating s= ize of library dependencies: If, as Albert says, only a handful of pack= ages may be eliminated from the build, even in the case that only a few rea= ders or writers were needed, and if the size of these packages is not vastl= y greater than the size of others, then clearly the material benefit of eli= minating certain readers and writers from the build is very limited. Howeve= r, I make a few notes:
    1. Is the reason that most dependencies wou= ld remain even after removing most of the readers and writers that these de= pendencies are needed separately by all the readers and writers, or rather = that they are needed by the core application? In the latter case, perhaps s= ome of the core functionality not needed in basic uses, again at least in p= rinciple, can be separated.
    2. My earlier question directed mostly= at the difficulty of determining confidently the complete set of dependenc= ies to remove, without invoking a formal solution such as graph traversal, = compared to the possibility of missing a set in an informal assessment.
      =
  2. Footprint of Runtime System: No, I was = not specifically aware of the size of the Runtime System. I am having diffi= culty finding a clear indication of how much size it adds to the final exec= utable size, but estimates that seem to recur are in the 10-15 megabyte ran= ge. If these estimates are accurate, then it would be impossible to achieve= vastly smaller sizes, obviously, but this information alone is not suffici= ent to conclude the impossibility of achieving significant savings through = methods already discussed. Also, I am seeing some hints that a GHC backend = for LLVM is available that makes possible much more optimal build results. = Unfortunately, I have not found any quantitative assessment of these saving= s, nor can I find any active project maintaining this interface.

--
You received this message because you are subscribed to the Google Groups &= quot;pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pand= oc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To view this discussion on the web visit https://groups.google.com/d/= msgid/pandoc-discuss/f9fd9cfe-e03f-45d3-bcb5-07267c28e565%40googlegroups.co= m.
------=_Part_307_620266579.1588574709427-- ------=_Part_306_52846467.1588574709427--