<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 10:39 AM, Motiejus Jakštys <span dir="ltr"><<a href="mailto:desired.mta@gmail.com" target="_blank">desired.mta@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Tue, Feb 18, 2014 at 9:34 AM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>

> Here's a radical proposal. The top level package should be a PDF file.<br>
><br>
> In 2001 ago I wrote this<br>
><br>
> <a href="http://www.sics.se/~joe/erlpdf.pdf" target="_blank">http://www.sics.se/~joe/erlpdf.pdf</a> - Read it, download it, try it, think<br>
> about it.<br>
<br>
Does not render correctly in my document viewer (evince) and does not<br>
render at all in Iceweasel 25 embedded pdf viewer.<br></blockquote><div><br></div><div>That's strange It displays correctly in my evince (vsn 3.4.0)  and also in adobe reader 9.</div><div>I follow the PDF standard (At least I hope I do) so it should be ok.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
> This a simple program that packs a file inside a PDF container. It still<br>
> works.<br>
<...><br>
> Q: Why should the top level package be a PDF file?<br>
> A: Because the *first* thing I want to do is read the documentation.<br>
>    I won't even look at a program that has no documentation - it's a waste<br>
> of time.<br>
<br>
I could agree if I really needed to*. But:<br>
1. Not everything can be pre-compiled (nifs and port drivers come to mind)<br></blockquote><div><br></div><div>I was thinking of having pre-compiled binaries for different OSs here</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

2. This severely limits the documentation representation. What if my<br>
documentation is a rich Web Page which requires html5 to tickle my<br>
fancy? In PDF we are sort of limited to... PDF.<br></blockquote><div><br></div><div>You could put all the beam code/whatever in a </div><div><br></div><div><script type="text/javascript"><!--//--><![CDATA[//><!--</div>
<div>    My Beam code here ... ()ore erlang)</div><div>//--><!]]></script></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
A quick fix for 2014 onwards: we have OpenDocument and Office Open XML<br>
which are just zip files with many more tools to manipulate. Loading<br>
stuff from zip archives is something we already do (except nifs, yes).<br>
We just need a file extension.<br>
<br></blockquote><div><br></div><div>Indeed - I just wanted the top level to be the documentation since that's what's I wanted to see first.</div><div>You could put inside a  jpeg file as an exif comment I guess and have pictures of earwigs for all I care.</div>
<div>The point is that it's in a container that should not be unpacked.</div><div><br></div><div>/Joe</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

:: EAR ::<br>
<br>
Motiejus<br>
</blockquote></div><br></div></div>