Il giorno mercoledì 2 maggio 2018 17:51:24 UTC+2, Robert Johnstone ha
scritto:
>
> Before there was a wide range of tools for embedding assets, I wrote my
> own. It is relatively complete, but it did not have a feature to create a
> debug mode for assets. However, the server took a command-line flag for
> debug mode, and would access assets through the file system instead of the
> embedded data.
>
> The point being, the "standard" tool would not have to support everything,
> it could be a building block for other packages. The key functionality
> would be embedding possibly large assets into the linked executable. I
> haven't measured in a while, but embedding assets did have a significant
> impact on build times. Finding the most efficient technique would be a
> usable block, all on its own. Additional conveniences could be built on
> top.
>
> Robert
>
>
Beside a "standard" tool, maybe we need a "standard" interface; e.g.
package data
type Asset interface {
Load(path string) (io.Reader, error)
}
and have some default implementations.
Assets can be stored in several place, like
- Global system path (/usr/share)
- Local system path (/usr/local/share)
- User path (~/.local/share)
- A Custom path
- Embedded in the executable
Manlio
> On Wednesday, 2 May 2018 10:36:43 UTC-4, mbanzon wrote:
>>
>> I’m guessing that everyone who has a workflow where they currently embed
>> resources in their binary will have specific wishes to how it’ll function.
>>
>> The “easy” way to make serious proposals is to provide an experiment
>> where you demonstrate the change you are proposing with an implementation -
>> this will naturally require some work.
>>
>> My/our use of embedded resources include other programs but especially
>> frontends (html, css, javascript and images, fonts etc.) for web servers -
>> the current solution give us a crucial feature: The files are not embedded
>> during development/debugging where they change continually.
>>
>> There is no doubt that I’d welcome this feature in the standard Go
>> toolchain - where it is implemented or how the resource is embedded is not
>> really something I have a strong opinion about - but debugging capabilities
>> is ;-)
>>
>> --
>> Michael Banzon
>> https://michaelbanzon.com/
>>
>>
>>
>>
>> Den 2. maj 2018 kl. 14.35 skrev Manlio Perillo <manlio....@gmail.com>:
>>
>> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha
>> scritto:
>>>
>>> On Tue, May 1, 2018 at 1:28 PM, John Unland <unlan...@gmail.com> wrote:
>>> >
>>> > So something like x/tools/cmd/assets or cmd/assets?
>>>
>>> Yes. I might use a name more like cmd/embed.
>>>
>>>
>>> > I was just now thinking about it more today and I was wondering if
>>> something
>>> > like this could maybe be implemented into go build. Like how you can
>>> assign
>>> > variables at build time:
>>> >
>>> > go build -ldflags="-X main.Foo=Bar"
>>> >
>>> > Into something like...
>>> >
>>> > go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB"
>>> >
>>> > Think this would take a little more effort to integrate in but it's a
>>> > interesting concept thou.
>>>
>>> Personally I think the code generation approach is simpler.
>>>
>>>
>> It is simpler but, isn't it very inefficient with large assets, since the
>> compiler eats a lot of memory?
>> Maybe a better choice is to directly embed the code into the executable
>> image, as an example appending a zip archive at the end of the executable
>> (this at least works with ELF on Linux).
>>
>> Using a zip archive appended to the end of the executable, you don't even
>> need to record the offset.
>> The unzip tool just reports a warning:
>> warning [xxx]: ddd extra bytes at beginning or within zipfile
>>
>> I have not tested it with the archive/zip package.
>>
>>
>> Manlio
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
