In my opinion, currently there is no need for Go 'standardization'. There
aren't multiple implementation of Go where each vendor is eager to add their
own features and promote their own version of Go.
In fact, by giving up control to a committee (especially during this early
stage of the langu
On Fri, Oct 12, 2018 at 11:29 AM, wrote:
>
> I was wondering if there's a particular reason to enforce importing golint
> from a certain source (see:
> https://github.com/golang/lint/commit/9a272034dedb2a3ed05231d5604ce17fb40f0e58).
> There seems to be a lot of code in "the wild" importing this p
On Fri, Oct 12, 2018 at 12:21 PM, Liam wrote:
>
> If there is already a member of the Go team doing outreach to government and
> enterprise IT managers, it would be interesting to hear from them re
> requirements they've heard from this category...
That is a fair question. At present the concern
Hi,
Ah I see what you mean. The cross compiled windows file will rely on the efl
library, but that can be packaged. This means that it would need to be a bigger
distribution than just the exe if you want all deps shipped (I’m not too
familiar with the windows terms yet).
I’ll try and get a doc
The migration is complete. Thanks all!
On Fri, Oct 12, 2018 at 3:28 PM Andrew Bonventre
wrote:
> This is starting now.
>
> On Fri, Oct 12, 2018 at 3:08 PM Andrew Bonventre
> wrote:
>
>> Hi tourists,
>> I have to take the tour down to migrate it to an App Engine service
>> (there is no way to ma
This is starting now.
On Fri, Oct 12, 2018 at 3:08 PM Andrew Bonventre
wrote:
> Hi tourists,
> I have to take the tour down to migrate it to an App Engine service (there
> is no way to make this change without a minimal amount of downtime).
>
> I will follow up when this work has begun. I plan t
I was wondering if there's a particular reason to enforce importing golint
from a certain source (see:
https://github.com/golang/lint/commit/9a272034dedb2a3ed05231d5604ce17fb40f0e58).
There seems to be a lot of code in "the wild" importing this project from
github.com as evinced by a number of
You may need to find a large organization with ISO-only policy to approach
the Go team directly, and help staff a standardization effort.
If there is already a member of the Go team doing outreach to government
and enterprise IT managers, it would be interesting to hear from them re
requirement
Hi tourists,
I have to take the tour down to migrate it to an App Engine service (there
is no way to make this change without a minimal amount of downtime).
I will follow up when this work has begun. I plan to start it within the
hour.
It should only be down for a few minutes, but that assumes ev
Is an alternate solution to use Go as a source language, then translate to
an allegedly "ISO" language?
Eric.
On Thursday, October 11, 2018 at 8:57:39 PM UTC-7, Beoran wrote:
>
> So no matter if I say yes or no, both ways are bad? I think is not a very
> fair way to argue.
>
> Anyway, with the
If I remember correctly, it would be something like this:
fd = open("/tmp", O_TMPFILE | O_RDWR, 0600);
linkat(fd, "", AT_FDCWD, "/tmp/test", AT_EMPTY_PATH);
This is pretty specific to OS/kernel version and quite possibly the filesystem
too. This could be entirely too much of an edge case to be
Paul, I fully agree with your ideas on what should be standardized. Either a
subset of Go1 or Go1 once Go2 is in full swing. Go++, perish the thought! >_<
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop re
If Go is to be standardized, it needs to be as late as possible in the
development of Go 1. My observations of being involved with some standards is
that the participants view it as an opportunity to change or add to whatever is
being standardized. Unless the standard was simply a true codific
I would not call it deceit, since the Ruby standard does accurately describes a
subset of Ruby v1.8. It is more a workaround for institutional rigidity.
I guess we would likely be better of without such bureaucracies, but it is
utopic to think they will disappear any time soon. The best we can d
Hi Guy,
Right now, my understanding is there is not a perfect answer to your
questions.
However, these are very important questions, including I think community
discussion right now can help establish alternative immediate solutions, as
well as help shape how things might work in 1.12 and beyo
Which is not Windows, which is giving up a lot of options, and is important to
some people, where as just using tmp files is ok. I am not even sure if windows
supports deleting an open file yet.
> On Oct 12, 2018, at 3:09 AM, Beoran wrote:
>
> linkat() and openat() are posix 2008 standard func
I'm not sure whether this way lies madness or whether the madness is the
starting point.
In a world not corrupted by daily fake news and gratuitous displays of
violence and human suffering and animal suffering for the sake of increased
profits, the concept of performing some sleight of hand to
linkat() and openat() are posix 2008 standard functions so I wouldn't call this
uncommon. As such they are useful to have in Go in one way or the other. The
x/unix package is fine for that, though.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group
18 matches
Mail list logo
