What brought me to it was the concurrency. I spent my entire career
frustrated by not only how concurrency wasn't more of a thing in popular
languages, but also how so many people didn't seem to think it was a
problem. I pounced on Go when I heard about it. (Although I am currently
fluttering
On Wednesday, February 27, 2019 at 2:58:40 AM UTC+1, Space A. wrote:
>
> Mentioned license doesn't cover binaries produced by compiler, "binary
> form" there means go tools themselves, and stdlib only when redistributed
> separately as a whole in binary form. When stdlib is used to compile
>
On Wed, Feb 27, 2019 at 6:56 AM Space A. wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I
> would argue that runtime IS part of language itself because language is not
> only a syntax. It also a garbage collector, a goroutines, etc, as you
> mentioned. You
On Wed, Feb 27, 2019 at 9:20 AM Space A. wrote:
> There is no "derivatives" in Go's license terms *at all*. There is only
> redistribution in binary and source form and it covers only what's in the
> repo (https://github.com/golang/go/blob/master/LICENSE).
>
> Compilation is not redistribution.
On Wed, Feb 27, 2019 at 3:20 PM Space A. wrote:
> This is 100% clear case and you can distribute your compiled binaries
free, without any additional requirements, restrictions, giving or not
credits, or binding yourself to some specific license, what so ever.
That's not correct. Quoting from
Jan, good that you read my link, however I already answered on this
(quoting myself):
Mentioned license doesn't cover binaries produced by compiler, "binary
> form" there means go tools themselves, and stdlib only when redistributed
> separately as a whole in binary form. When stdlib is used to
On Wed, Feb 27, 2019 at 3:47 PM Space A. wrote:
> Mentioned license doesn't cover binaries produced by compiler, "binary
form" there means go tools themselves ...
That would mean that once a copyrighted source code is compiled to binary
form, the source code copyright holders LICENSE terms no
You have very poor understanding of the subject, messing everything up.
There is no "derivatives" in Go's license terms *at all*. There is only
redistribution in binary and source form and it covers only what's in the
repo (https://github.com/golang/go/blob/master/LICENSE).
Compilation is not
Thank you, Go Team!
Installed.
My complex web app seems to work just fine under 1.12.
--
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
There is one place where derivative is irrelevant, that would be where a
patent sticks to the algorithm, and this patently idiotic situation is not
universally applicable, some jurisdictions never added this kind of lunacy
to copyright law (unfortunately, not all).
As I understand it, the
Hello,
Just after the new release of go 1.12, I migrated my project to use the new
version.
Every thing went fine so far, all tests and code coverage reports were
generated accruately just like before.
Once done I activated GO111MODULE option to get rid of the dep dependency
manager we were
This would only be true if *derivatives* were specified. Go links
everything static by default, so in *very* broad terms, the binaries are
derivative of the stdlib in the distributed go compiler package. I think
really the proper way to look at this is this exact subject is simply not
Regarding runtime - it's interesting (and separate question maybe), and I
would argue that runtime IS part of language itself because language is not
only a syntax. It also a garbage collector, a goroutines, etc, as you
mentioned. You just can't write Go program without having runtime. It's not
No that means that it will depend on what's written in this particular
license given by creator of this source codes. It's case by case. For
example they can say that compilation is not allowed at all. Go's repo
license is clear without any "derivatives" "commercial" or "personal"
complex use
You may look at https://www.gnu.org/licenses/gcc-exception-3.1-faq.html for
a reference.
Manlio Perillo
On Wednesday, February 27, 2019 at 3:56:10 PM UTC+1, Space A. wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I
> would argue that runtime IS part of
Hello,
Just after the new release of go 1.12, I migrated my project to use the new
version.
Every thing went fine so far, all tests and code coverage reports were
generated accruately just like before.
Once done I activated GO111MODULE option to get rid of the dep dependency
manager we were
For the embedded, https://tinygo.org/, but limited back ends.
On Wed, 2019-02-27 at 02:02 -0800, Chris Hopkins wrote:
> What brought me to it was the concurrency. I spent my entire career
> frustrated by not only how concurrency wasn't more of a thing in
> popular
> languages, but also how so
I have the same problem. Were you ever able to find the solution?
On Tuesday, January 8, 2019 at 5:42:37 AM UTC-8, aniruddh...@nytimes.com
wrote:
>
> I am Using go1.11.4 for postgres connection and strictly using GAE
> standard. My app.yaml is as below-
>
>
> runtime: go111
>
> service:
These two points really nail it:
On Wednesday, 27 February 2019 11:02:23 UTC+1, Chris Hopkins wrote:
>
>
> What made me stay is the clarity and simplicity. So many languages seem to
> be an exercise in showing off how clever you are, by using x clever
> pattern. Go doesn't seem to suffer this.
On Tue, Feb 26, 2019 at 11:34 PM Ian Lance Taylor wrote:
>
> On Tue, Feb 26, 2019 at 6:08 PM Gargi Sharma wrote:
> >
> > I meant the Section and SectionByType calls.
>
> Those calls do different things. They do more than just get the
> symbol table. They aren't equivalent.
>
>
> > [ 6]
Same again, messing everything. It's not API, we are talking about
distributing compiled executables.
ср, 27 февр. 2019 г. в 21:36, Robert Engels :
> You are not correct. There are current cases where apis are being claimed
> to be copyrighted. It is under active litigation.
>
> On Feb 27,
On Wed, Feb 27, 2019 at 9:41 AM Gargi Sharma wrote:
>
> On Tue, Feb 26, 2019 at 11:34 PM Ian Lance Taylor wrote:
> >
> > On Tue, Feb 26, 2019 at 6:08 PM Gargi Sharma wrote:
> > >
> > > I meant the Section and SectionByType calls.
> >
> > Those calls do different things. They do more than just
You are not correct. There are current cases where apis are being claimed to be
copyrighted. It is under active litigation.
> On Feb 27, 2019, at 8:19 AM, Space A. wrote:
>
> You have very poor understanding of the subject, messing everything up.
> There is no "derivatives" in Go's license
You are not correct. You might wish to read this
https://en.m.wikipedia.org/wiki/GPL_linking_exception which covers many of the
same issues, and how they think they resolved it.
> On Feb 27, 2019, at 12:45 PM, Space A. wrote:
>
> It's very clear case. It will never become a case in a court.
FYI, the Go 1.12 toolchain is now blessed by Symantec.
> I reported these false positives for the go command, compiler, assembler
> and linker at
> https://submit.symantec.com/false_positive/ and the good news is that the
> go command (1.12 version) is now whitelisted. I'm waiting for the
That is incorrect thinking. And again, it is all subject to litigation. Whether
you are right or wrong is up to the courts to decide.
> On Feb 27, 2019, at 8:55 AM, Space A. wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I
> would argue that runtime IS
It's very clear case. It will never become a case in a court. Otherwise, if
it ever will, I mean, compiling own program and distributing a binary which
used stdlib e.g. without kissing someone's ass - language is dead.
ср, 27 февр. 2019 г. в 21:39, Robert Engels :
> That is incorrect thinking.
You're claiming expertise in copyright law in at least two
jurisdictions, and claiming greater understanding of Australian
copyright legislation than a person who has had training in Australian
copyright legislation as part of their employment.
I'm done here.
On Wed, 2019-02-27 at 23:19 +0300,
Hi,
I would like to update a counter up to a certain limit atomically, without
using a channel or mutex. What do you think of the following (equivalent)
functions for sync/atomic?
func CompareAndInc(*addr, Max) bool {
if *addr < Max {
*addr++
return true
}
return false
}
func
Please read https://golang.org/conduct
Your comments here have been in my view contrary to this document.
On Wed, 2019-02-27 at 23:48 +0300, Space A. wrote:
> I could, of course, however I never did. And I'd like to keep myself
> out of
> the scope of discussion. If you re-read my messages,
GPL is another license with different terms, I would say offtopic.
ср, 27 февр. 2019 г. в 21:55, Robert Engels :
> You are not correct. You might wish to read this
> https://en.m.wikipedia.org/wiki/GPL_linking_exception which covers many
> of the same issues, and how they think they resolved it.
Pull your head in and stop being rude to people here.
On Wed, 2019-02-27 at 17:19 +0300, Space A. wrote:
> You have very poor understanding of the subject, messing everything
> up.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
Sorry? You have poor understanding and mess things, so what's wrong? Being
dilatant is not crime, it's okay unless you start convincing yourself that
false is true.
ср, 27 февр. 2019 г. в 22:41, Dan Kortschak :
> Pull your head in and stop being rude to people here.
>
> On Wed, 2019-02-27 at
On Wed, Feb 27, 2019 at 12:46 PM Serhat Şevki Dinçer wrote:
>
> I would like to update a counter up to a certain limit atomically, without
> using a channel or mutex. What do you think of the following (equivalent)
> functions for sync/atomic?
>
> func CompareAndInc(*addr, Max) bool {
>
> if
I could, of course, however I never did. And I'd like to keep myself out of
the scope of discussion. If you re-read my messages, you'll find they were
focused on topic, not shifting to persons. Thank you for your
participation, it's always good to hear different opinions, even if they
are not
Am Dienstag, 26. Februar 2019 13:07:58 UTC+1 schrieb Louki Sumirniy:
>
>
> Many other languages force you to really separate coding and architecting,
> Go lets you do it all on-the-fly.
>
This is fine as long as you work your design around the capabilites of
Golang. If not...
Sounds trivial
The new ABI broke Go-QML compilation
(https://github.com/go-qml/qml/issues/190). The error is:
cdata.Ref: relocation target runtime.acquirem not defined for ABI0 (but is
defined for ABIInternal)
cdata.Ref: relocation target runtime.releasem not defined for ABI0 (but is
defined for
I was able to solve, I will comment into the issue how I did it.
--
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
On Wed, Feb 27, 2019 at 2:42 PM wrote:
>
> In Go functions can be used before they are defined, but as I understand,
> it's still possible to have a single pass compiler.
I don't think it's possible to compile Go in a single pass compiler,
unless you consider a separate parsing and code
https://github.com/golang/go/issues/30374 seems to be the issue and
apparently, there's a workaround:
> The workaround for now is to include at most one `main` package in the
`-coverpkg` arguments, or to run coverage in `GOPATH` mode.
On Wednesday, February 27, 2019 at 6:01:33 AM UTC-8,
Thanks, Ian.
I remember reading in some compiler book that languages should be designed
for a single pass to reduce compilation speed.
Go proves that wrong :) It's amazingly fast, looks like computers are
pretty good at traversing AST trees.
On Wednesday, February 27, 2019 at 11:50:05 PM
Hello,
In Go functions can be used before they are defined, but as I understand,
it's still possible to have a single pass compiler.
Thanks
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
The Go compiler was single pass until we allowed use before declaration.
-rob
On Thu, Feb 28, 2019 at 10:46 AM wrote:
> Thanks, Ian.
>
> I remember reading in some compiler book that languages should be designed
> for a single pass to reduce compilation speed.
>
> Go proves that wrong :) It's
Indeed, this is what I just checked this morning and saw whil generating
coverage info on a "per package" basis
I'll check the issue status over the next weeks
Thanks for your help
Best regards
Le jeudi 28 février 2019 01:07:55 UTC+1, Krzysztof Kowalczyk a écrit :
>
>
Please take a look at this article
https://blog.learngoprogramming.com/a-visual-guide-to-golang-memory-allocator-from-ground-up-e132258453ed
TOP will show you all virtual memory which kernel reserved for
application, not a memory used by application.
On 27.02.2019 10:20, Lee Rick wrote:
在
45 matches
Mail list logo
