On Wednesday, May 2, 2018 at 3:12:58 PM UTC-5, Manlio Perillo wrote:
> Yes, but many developers may need a "debug" mode or more options available
> to where to store the assets.
> Why should a "standard" tool or API be restricted to where to store assets?
>
I can kinda see where your going with
Il giorno mercoledì 2 maggio 2018 21:53:50 UTC+2, Jan Mercl ha scritto:
>
> On Wed, May 2, 2018 at 9:23 PM Manlio Perillo > wrote:
>
> > Note that you can load assets of any package, not only of the "current"
> package.
>
> No doubt that's useful, but the topic of this thread is about embedded,
On Wed, May 2, 2018 at 9:23 PM Manlio Perillo
wrote:
> Note that you can load assets of any package, not only of the "current"
package.
No doubt that's useful, but the topic of this thread is about embedded,
static assets, fixed at link time.
--
-j
--
You received this message because you ar
Il giorno mercoledì 2 maggio 2018 20:47:19 UTC+2, Jan Mercl ha scritto:
>
> On Wed, May 2, 2018 at 8:31 PM Manlio Perillo > wrote:
>
> > The interface is different.
> >
> > Open(pkg, path string) ...
>
> Please explain why the 'pkg' argument is needed. Paths can encode any
> hierarchy.
>
>
This i
On Wed, May 2, 2018 at 8:31 PM Manlio Perillo
wrote:
> The interface is different.
>
> Open(pkg, path string) ...
Please explain why the 'pkg' argument is needed. Paths can encode any
hierarchy.
> You also need the package import path to load an asset.
I do not understand the connection.
FTR:
Il giorno mercoledì 2 maggio 2018 20:02:12 UTC+2, Jan Mercl ha scritto:
>
> On Wed, May 2, 2018 at 7:39 PM Manlio Perillo > wrote:
>
> > type Asset interface
>
> bike shedding: type Assets = http.FileSystem
> --
>
The interface is different.
Open(pkg, path string) ...
You also need the packa
On Wed, May 2, 2018 at 7:39 PM Manlio Perillo
wrote:
> type Asset interface
bike shedding: type Assets = http.FileSystem
--
-j
--
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,
Il giorno mercoledì 2 maggio 2018 19:23:59 UTC+2, Manlio Perillo ha scritto:
>
> 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
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-lin
On Wed, May 2, 2018 at 6:45 PM, Ian Lance Taylor wrote:
> On Wed, May 2, 2018 at 5:35 AM, Manlio Perillo
> wrote:
>> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha
>> scritto:
>>
>>> Personally I think the code generation approach is simpler.
>>>
>>
>> It is simpler but, i
On Wed, May 2, 2018 at 5:35 AM, Manlio Perillo wrote:
> Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha
> scritto:
>
>> 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
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
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 - thi
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 > 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 t
On Tue, May 1, 2018 at 1:28 PM, John Unland 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
So something like *x/tools/cmd/assets* or *cmd/assets*?
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.
On Mon, Apr 30, 2018 at 12:10 PM, John Unland wrote:
>
> Don't think so, I think most tools out there have the same basic premise
> behind embedding assets. I think it would be great to have one standard tool
> into the stdlib. Since Go is a language for the web this would align greatly
> with som
Don't think so, I think most tools out there have the same basic premise
behind embedding assets. I think it would be great to have one standard
tool into the stdlib. Since Go is a language for the web this would align
greatly with something like this.
On Monday, April 30, 2018 at 1:09:02 PM UT
On Mon, Apr 30, 2018 at 7:03 AM, John Unland wrote:
>
> Hey everyone I've been mulling over this for a couple of days, thought I
> would get some feed back on the possibility of shooting a proposal to have
> embedding static assets into the stdlib. From the looks of it this wouldn't
> break Go 1 c
Hey everyone I've been mulling over this for a couple of days, thought I
would get some feed back on the possibility of shooting a proposal to have
embedding static assets into the stdlib. From the looks of it this wouldn't
break Go 1 compatibility thou I'm wondering if it would be better to jus
20 matches
Mail list logo
