Embed files into binary.

[Pie? via Digitalmars-d-learn]

On Monday, 6 June 2016 at 03:23:02 UTC, rikki cattermole wrote:
> On 06/06/2016 3:11 PM, Pie? wrote:
>> On Monday, 6 June 2016 at 02:34:07 UTC, Adam D. Ruppe wrote:
>>> On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
>>>> I believe the essentially converted the file into a ubyte or
>>>> something and then wrote that out to a temp file and read in 
>>>> the temp
>>>> file... this seems a bit of a kludge to me.
>>>
>>> They might do that for certain special cases, but
>>> import("file.whatever") just drops the file content in memory 
>>> and you
>>> can then access it as an array.
>>>
>>>> Because D allows such an embedding feature, maybe the file 
>>>> system
>>>> should allow working with this concept?
>>>
>>> Why do you need it through the file system? If you're writing 
>>> the
>>> code, just use the array in memory. If it is external, see if 
>>> the
>>> library offers something like that.
>>>
>>> DLL and exe are a special case, most things don't need to be 
>>> physical
>>> files.
>>
>> Because, as I said, if I'm working with pre-exiting modules 
>> that work
>> with file, I have to provide a file or modify the source.
>>
>> e.g., how could I do this easily with your read in your png 
>> module? It
>> takes a file..
>>
>> /// Easily reads a png file into a MemoryImage
>> MemoryImage readPng(string filename) {
>>     import std.file;
>>     return imageFromPng(readPng(cast(ubyte[]) read(filename)));
>>
>> recognize the code?
>>
>> Of course, like I said, it can be modified in this case, but 
>> that means
>> nothing in general.
>
>
> ubyte[] theArray = import("...");
> MemoryImage img = imageFromPng(readPng(theArray));
>
> And that's just from the snippet you provided.
> Yay overloads!

Yes, I figured it could be done because of the MemoryImage, but 
that wasn't the point.  You are delving in to code that you might 
not normally have access or might not exist.

Adam wrote the MemoryImage that essentially does this but that is 
not the general case.

Image if all you access to was readPng(string filename), then 
what would you say? That was my point of posting the code, I 
didn't mean for you to go look and see if it was possible to 
achieve what I was saying in arsd(Formally known as Adam Druppe) 
git repository ;)

If that was the case I would have titled this something similar 
not but maybe not exactly equivalent(Just being pedantic since we 
seem to be having a communications gap in how accurate and 
precise our expressions are to be interpreted): "Possible to get 
arsd(Formally known as Adam Druppe) readpng lib to read from 
import(filename)?".

Since I was desiring to arrive at a more general solution to 
potential future programming goals, I phrased my question in more 
general terms. I assumed that this would be understood. (i.e., 
vague questions generally gets/desires vague results, intelligent 
questions generally get/desires intelligent results, etc.)

In fact, I posted the most generic(and possibly vague) question I 
could:

"Embed files into binary."  I stated, but not exclaimed or 
questioned(as these are in theory, mutually exclusive), in the 
subject line!

But this is no question! It is a riddle my friend! By stating it 
in such a way as to only imply the logical consequent "How to use 
embedded files in the binary"[Of course, with an infinite number 
of assumptions mixed in for spice]!

Why is this a necessary forgone conclusion, as Einstein would 
some times say(not to me in particular, mind you)?  Because there 
is no point to embed files in a binary if one can not use them!!!

Naturally, this is why I further said, in a round about way, why 
exporting them to temp files is not really an option. This was 
further to exclude, if you are keeping track with your Venn 
Diagram, something akin to the infinite monkey theorem... or a 
breach in the space time continuum.... or just several responses 
about along the lines "...save the data to a temp file and use 
that".

Note my retort:

">>>> Because D allows such an embedding feature, maybe the file
>>>> system
>>>> should allow working with this concept?"

Asking about future events and possibly space-time paradoxes!

For example, what if I derive some source code from some 
unexpected places and they have some complex way of using D's 
std.file routines and offers no interface to use memory arrays as 
an input? Suppose further that it is very contorted and only 
Steven Hawkins has figured out how to unravel the complexities of 
the law of import/export. We are not privy to his knowledge or 
intellectual properties. Would it not be intelligent and 
forthright, mimicking Steven Hawkins in a sort of motherly 
daughterly bond kind of way, to see that we must write new code 
to solve the problem... this timing mimicking God himself as he 
bought forth the earth and heaven?


Does that make sense?