Re: [go-nuts] Inconsistent reporting of unused package variable initialized in init() but used elsewhere
Global vars are inherently problematic. As mirtchov...@gmail.com noted you are shadowing the global var in your first example. Which is why the global var isn't updated. I'm only responding because as a grey beard I am dismayed that today I see so many instances of global vars that should have more limited scope. On Sat, Feb 23, 2019 at 8:34 PM wrote: > Hello, > > It's likely that I'm misinterpreting the language spec. It's also easy to > circumvent by assigning the offending variable to _. Even if this turns > out to be complying with the spec, thought this post may help anyone else > looking up this forum for answers. > > https://play.golang.org/p/5P5vcebYkGj reports an unused error for a > package variable initialized inside init() even though it's used elsewhere. > In this case doSomething() has 2 return values, one of which is the package > variable while the other is local. > > https://play.golang.org/p/DBXdNOHAA2Z does not report an error for a > package variable initialized inside init(). In this case doSomething() has > a single return value. > > https://play.golang.org/p/pdz2mMnQ_EZ similarly does not report an error > for 2 package variables initialized inside init(). In this case > doSomething() has 2 return values as well. > > Thanks > > -- > 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. > -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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.
Re: [go-nuts] Inconsistent reporting of unused package variable initialized in init() but used elsewhere
in https://play.golang.org/p/5P5vcebYkGj you're shadowing s by creating a new variable via := this is a common go interview question :) On Sat, Feb 23, 2019 at 9:34 PM wrote: > > Hello, > > It's likely that I'm misinterpreting the language spec. It's also easy to > circumvent by assigning the offending variable to _. Even if this turns out > to be complying with the spec, thought this post may help anyone else looking > up this forum for answers. > > https://play.golang.org/p/5P5vcebYkGj reports an unused error for a package > variable initialized inside init() even though it's used elsewhere. In this > case doSomething() has 2 return values, one of which is the package variable > while the other is local. > > https://play.golang.org/p/DBXdNOHAA2Z does not report an error for a package > variable initialized inside init(). In this case doSomething() has a single > return value. > > https://play.golang.org/p/pdz2mMnQ_EZ similarly does not report an error for > 2 package variables initialized inside init(). In this case doSomething() has > 2 return values as well. > > Thanks > > -- > 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. -- 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.
[go-nuts] Inconsistent reporting of unused package variable initialized in init() but used elsewhere
Hello, It's likely that I'm misinterpreting the language spec. It's also easy to circumvent by assigning the offending variable to _. Even if this turns out to be complying with the spec, thought this post may help anyone else looking up this forum for answers. https://play.golang.org/p/5P5vcebYkGj reports an unused error for a package variable initialized inside init() even though it's used elsewhere. In this case doSomething() has 2 return values, one of which is the package variable while the other is local. https://play.golang.org/p/DBXdNOHAA2Z does not report an error for a package variable initialized inside init(). In this case doSomething() has a single return value. https://play.golang.org/p/pdz2mMnQ_EZ similarly does not report an error for 2 package variables initialized inside init(). In this case doSomething() has 2 return values as well. Thanks -- 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.
Re: [go-nuts] How is a for loop preempted in Go?
Quoting David Finkel (2019-02-23 16:09:18) >Not only is fmt.Printf a function call, but it makes a blocking >syscall >(write specifically), >which gives the go runtime license to spin up a new OS thread and >immediately schedule the other goroutine. >runtime.GOMAXPROCS(1) only tries to guarantee that one OS thread >executing Go code will be executing at a time. >(this has no bearing on the revised version without a call to >fmt.Printf().) Good point. This is also important because "pre-emption at function calls" is not entirely reliable, since a function call could possibly be in-lined or otherwise optimized in a way that mucks with things -- whereas blocking is going to be more reliable in this way. -- 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.
Re: [go-nuts] How is a for loop preempted in Go?
[The other responses have been excellent, but I wanted to point one thing
out.]
On Fri, Feb 22, 2019 at 3:17 AM Jingguo Yao wrote:
> Consider the following code which launches two goroutines. Each
> goroutine uses a for loop to print messages.
>
> package main
>
> import (
> "fmt"
> "runtime"
> "time"
> )
>
> func main() {
> count := runtime.GOMAXPROCS(1)
> fmt.Printf("GOMAXPROCS: %d\n", count)
>
> // goroutine 1
> go func() {
> for {
> fmt.Printf("1")
> }
> }()
>
> // goroutine 2
> go func() {
> for {
> fmt.Printf("2")
> }
> }()
>
> time.Sleep(20 * time.Second)
> }
>
> The code uses runtime.GOMAXPROCS(1) to make the Go runtime has only
> one processor (P). So there is only one OS thread (M) to run
> goroutines. Without preemption, the M will run goroutine 1 or
> goroutine 2 continuously. The messages sent to the terminal should be
> all 1s or all 2s. But running the code prints interleaved 1s and 2s to
> the terminal, which means that some preemption happens. But
>
> https://www.quora.com/How-does-the-golang-scheduler-work/answer/Ian-Lance-Taylor
> says that:
>
> > A G can only be pre-empted at a safe point, which in the current
> > implementation can only happen when the code makes a function call.
>
> Since both goroutines do not make any function calls, there should be
> some other way to preempt a G. Can anyone give me an explanation of
> such kind of preemption?
>
Not only is fmt.Printf a function call, but it makes a blocking syscall
(write specifically),
which gives the go runtime license to spin up a new OS thread and
immediately schedule the other goroutine.
runtime.GOMAXPROCS(1) only tries to guarantee that one OS thread executing
Go code will be executing at a time.
(this has no bearing on the revised version without a call to fmt.Printf().)
>
> --
> 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.
>
--
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.
Re: [go-nuts] Visual Studio Code oddity with Go
Rich, you should check where your GOPATH is pointing. My guess is that VSCode is successfully installing the tool, but it's installing it in the "wrong" place. I have my $GOPATH is set to "\go" and my project folder structure is "$GOPATH\src\myDomain.com\myProject\main.go" and when I run VSCode I open the top-level $GOPATH folder. That way, I see all the tools that the VSCode Go Extension recommends to installation go in the "$GOPATH\go\src\github.com\.." and the "$GOPATH\go\golang.org.." in the folder explorer side-bar (screenshot attached). Hope that helps! On Friday, February 22, 2019 at 12:03:59 AM UTC-5, Rich wrote: > > Yeah. When I install the tool, it always gives me a success. When I > selected all of them it also gave me a success. > > Thanks! > > On Thursday, February 21, 2019 at 10:42:33 PM UTC-5, andrey mirtchovski > wrote: >> >> > I tried the solution posted by Andrey (Thank you!) and it still does >> the popup thing. Oh well, it's a minor distraction, click update and it >> goes away. >> >> If you go to the OUTPUT tab does it give you an error message? or does >> it say "things successfully installed"? >> > -- 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.
[go-nuts] Unmarshal nested XML value from dynamic XML document
Walk over it usin xml.Decoder.Token, and UnmarshalElement when found a StartToken with a proper Name.Local. -- 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.
Re: [go-nuts] How is a for loop preempted in Go?
Ian:
Thanks for your explanation.
On Saturday, February 23, 2019 at 1:13:04 AM UTC+8, Ian Denhardt wrote:
>
> In the new example, goroutine 2 should get pre-empted at time.Sleep.
> goroutine 1 may hog a CPU however. There's an open issue about this,
> which is being worked on.
>
> https://github.com/golang/go/issues/10958
>
> I think it's always been the intent that from the programmer's
> perspective goroutines don't block one another at all; they're just
> like threads but cheaper -- and indeed most of the time you can write
> code that acts like that's true and never see a problem -- but the
> reality of the implementation is that right now it is possible to
> tight-loop and block other goroutines.
>
> -Ian
>
> Quoting Jingguo Yao (2019-02-22 03:31:55)
> >Yes, my fault. Thanks for pointing it out.�
> >What happens if I remove the fmt.Printf function calls to have the
> >following code:
> >package main
> >import (
> >"fmt"
> >"runtime"
> >"time"
> >)
> >func main() {
> >count := runtime.GOMAXPROCS(1)
> >fmt.Printf("GOMAXPROCS: %d\n", count)
> >� // goroutine 1
> >go func() {
> >for {
> >}
> >}()
> >� // goroutine 2
> >go func() {
> >for {
> >}
> >}()
> >time.Sleep(10 * time.Second)
> >}
> >Can goroutine 1 or goroutine 2 be preempted? If yes, by which
> >mechanism?
> >On Friday, February 22, 2019 at 4:20:12 PM UTC+8, Ian Denhardt wrote:
> >
> > Quoting Jingguo Yao (2019-02-22 03:17:33)
> > > � � Since both goroutines do not make any function calls
> > fmt.Printf is a function.
> >
> >--
> >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 [1]golang-nuts...@googlegroups.com .
> >For more options, visit [2]https://groups.google.com/d/optout.
> >
> > Verweise
> >
> >1. mailto:golang-nuts+unsubscr...@googlegroups.com
> >2. 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.
[go-nuts] Unmarshal nested XML value from dynamic XML document
Hi all,
although I'm sure this question came up already I wasn't able to find a
solution for my issue.
I have this example XML structure:
{D4564-4564-456-4564456}
I want to unmarshal the ID value contained in the XML tags.
However this XML structure is dynamic, the embedding XML tag (in this case
) changes with every request.
How can I unmarshal the return value universally?
I have setup a little example: https://play.golang.org/p/j4ttdgW4W77
Also I've read this paragraph in the package documentation:
* If the XML element contains a sub-element whose name matches
a struct field's XMLName tag and the struct field has no
explicit name tag as per the previous rule, unmarshal maps
the sub-element to that struct field.
I dont' know what is meant with "XMLName tag" in this context, but I think
it might think it might point to a solution?
Thanks for any suggestions and hints,
Steffen
--
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.
Re: [go-nuts] Good metaphor for differentiating Go from other languages?
For me Go is the small but complete toolbox you need to build anything. Tim Allens Home Improvement and Binford comes to my mind :-) Randall O'Reilly schrieb am Sa. 23. Feb. 2019 um 05:40: > On the topic of “selling” the advantages of Go vs. other languages such as > Python and C++, has anyone used the metaphor of other products that > strongly emphasize clean, elegant design, such as Apple hardware (I > wouldn’t make this case about their software, given the nature of > objective-C and Swift), the Tesla cars, and other such “icons” of modern > design? It just occurred to me that this might be a powerful way to relate > in one simple way what it is that people find so appealing about Go. By > comparison, every other language is clunky and ugly, etc.. > > e.g., I could imagine someone writing something like this: > > https://www.smithsonianmag.com/arts-culture/how-steve-jobs-love-of-simplicity-fueled-a-design-revolution-23868877/ > > about Go vs. other programming languages, and in the process, really > communicating the essence of what is so great about the language in a way > that people can tangibly understand. I see so many discussions and > misunderstandings about Go being “kinda like C” and that is just so far > from the mark. > > Rob Pike’s talk: > https://talks.golang.org/2015/simplicity-is-complicated.slide#1 makes all > these points of course, very compellingly, but I wonder if adding the > simple point “Go is the Bauhaus of programming languages" as a kind of > tag-line. The practical problem is that many people probably don’t know > Bauhaus anymore, and saying “Go is the Apple of programming languages” has > all kinds of issues... Tesla? Steve Jobs instead of Apple? > > - Randy > > -- > 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. > -- 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.
