[go-nuts] git-codeview problem with multiple commits

[phil]

Hi folks,


I am trying to follow "Multiple-Commit Work Branches" paragraph in the 
git-codereview docs, but it seems to be missing a few steps.

( https://godoc.org/golang.org/x/review/git-codereview )


I've even tried ensuring that the Change-Id value is the same on all 
commits.. but it still refuses to allow me to run "git-codereview change".
so.. what should I do now?
git-codereview submit?
git push?


   #

$ git-codereview change
git-codereview: cannot amend change: multiple changes pending:
4e532a0 Updated call to fcntl with now-required third-arg cast to 
uintptr
93ac2bc Updated third parameter of fcntl to match new definition
98890de update type of fcntl to properly have 3rd arg as uintptr, to be 
fully standard compliant
c6af486 Exported fcntl as Fcntl
fa0af6a New test based around flock_test.go, but using Fcntl directly, 
rather than FcntlFlock

??


I'm confused, because I just did as the documentation said: 
invoke “git commit” directly, instead of “git codereview change”.

But I didnt run a blank change, before my first commit.
Does the documentation need to say, 
"use git change for your first commit, but git commit for subsequent 
changes" ?


and what do I do now?

-- 
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] Re: Scheduler discrepancy between Linux and OS X with Gosched()

[Dave Cheney]

> But is it not guaranteed that runtime.Gosched() will at least check if 
another goroutine is runnable?

It checks, but I believe that at the time that it checks there are often no 
other runnable goroutines. The execution tracer will give you the answer to 
this.

On Wednesday, 4 April 2018 04:12:40 UTC+10, brianbl...@gmail.com wrote:
>
> Hi Dave, thanks for the reply!
>
> It makes sense that the send c <- 0 is not guaranteed to transfer control 
> to the receiving goroutine. But is it not guaranteed that runtime.Gosched() 
> will at least check if another goroutine is runnable? I thought that was 
> roughly the point of runtime.Gosched(). 
>
> I see what you're saying in that when the second goroutine calls Gosched, 
> the sleep period may not be finished. But this will only waste another 100 
> microseconds by design (not 100 milliseconds), so it seems like control 
> flow should return to the main goroutine approximately when the sleep call 
> finishes.
>
> I created a simpler example, that doesn't use channels and avoids the work 
> length ambiguity, posted below. Now the secondary goroutine just does an 
> infinite loop of runtime.Gosched(). It should be instantaneous to run (and 
> is on my Mac), but it takes almost exactly 5 seconds on Ubuntu, suggesting 
> that there is some fixed 5 millisecond delay on Gosched(). And adding a 
> print above spin's Gosched makes it instantaneous.
>
> Thanks for your patience! I'm working on an application where the ~5ms 
> Gosched delay is meaningful and I am very curious to figure out what's 
> going on here. 
> package main
>
> import (
> "log"
> "runtime"
> "time"
> )
>
> func spin() {
> for {
> runtime.Gosched()
> }
> }
>
> func main() {
> runtime.GOMAXPROCS(1)
> go spin()
>
> t0 := time.Now()
> for i := 0; i < 1000; i++ {
> time.Sleep(10 * time.Microsecond)
>
> runtime.Gosched()
> }
>
> log.Printf("Finished in %v.", time.Since(t0))
> }
>
>
> On Tuesday, April 3, 2018 at 12:56:49 AM UTC-4, brianbl...@gmail.com 
> wrote:
>>
>> I've run into some mysterious behavior, where Gosched() works as expected 
>> in Mac OS X, but only works as expected in Ubuntu if I put a logging 
>> statement before it.
>>
>> I originally posted this on Stack Overflow but was directed here. Post: 
>> https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x
>>
>> Any help would be greatly appreciated! Very curious what's going on here, 
>> as this behavior came up while I was trying to write a websocket broadcast 
>> server. Here's a minimal setup that reproduces the behavior:
>>
>> The main goroutine sleeps for 1000 periods of 1ms, and after each sleep 
>> pushes a dummy message onto another goroutine via a channel. The second 
>> goroutine listens for new messages, and every time it gets one it does 10ms 
>> of work. So without any runtime.Gosched() calls, the program will take 
>> 10 seconds to run.
>>
>> When I add periodic runtime.Gosched() calls in the second goroutine, as 
>> expected the program runtime shrinks down to 1 second on my Mac. However, 
>> when I try running the same program on Ubuntu, it still takes 10 seconds. I 
>> made sure to set runtime.GOMAXPROCS(1) in both cases.
>>
>> Here's where it gets really strange: if I just add a logging statement 
>> before the the runtime.Gosched() calls, then suddenly the program runs 
>> in the expected 1 second on Ubuntu as well.
>>
>>
>> package main
>> import (
>> "time"
>> "log"
>> "runtime")
>>
>> func doWork(c chan int) {
>> for {
>> <-c
>>
>> // This outer loop will take ~10ms.
>> for j := 0; j < 100 ; j++ {
>> // The following block of CPU work takes ~100 microseconds
>> for i := 0; i < 30; i++ {
>> _ = i * 17
>> }
>> // Somehow this print statement saves the day in Ubuntu
>> log.Printf("donkey")
>> runtime.Gosched()
>> }
>> }}
>>
>> func main() {
>> runtime.GOMAXPROCS(1)
>> c := make(chan int, 1000)
>> go doWork(c)
>>
>> start := time.Now().UnixNano()
>> for i := 0; i < 1000; i++ {
>> time.Sleep(1 * time.Millisecond)
>>
>> // Queue up 10ms of work in the other goroutine, which will backlog
>> // this goroutine without runtime.Gosched() calls.
>> c <- 0
>> }
>>
>> // Whole program should take about 1 second to run if the Gosched() 
>> calls 
>> // work, otherwise 10 seconds.
>> log.Printf("Finished in %f seconds.", float64(time.Now().UnixNano() - 
>> start) / 1e9)}
>>
>>
>>

-- 
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] Re: Help with XML parsing

[Mandolyte]

I have some utilities that should give you some help. Documented in three 
blog articles. Here is the first one.

http://www.mandolyte.info/2017/12/encodingxml.html

which points to a generic parser that can be used on any XML document (I 
think :-)) and outputs a CSV "report".

HTH,
Cecil

On Tuesday, April 3, 2018 at 4:47:49 PM UTC-4, XXX ZZZ wrote:
>
> Hello,
>
> I'm trying to parse an XML with golang but I'm having a hard time creating 
> a parser for the string, in fact I couldn't even get an output using 
> interface{}.
>
> package main
>
> import (
> "fmt"
> "encoding/xml"
> )
>
>
> type MMXML_Listing struct {
> Original_title string `xml:"title"`
> Original_desc   string `xml:"description"`
> Original_domain   string `xml:"displayurl"`
> Original_URL   string `xml:"clickurl"`
> }
>
> type MMXML_HostProperties struct {
> Tags[]MMXML_Listing`xml:"response>adverts>advert"`
> }
> const s = ` results="1" search="806848020741095496" query="whatsapp" country="XX" 
> platform="zzz" currency="USD" guid="FP.66.66.66.61"> provider="0" bid="1" campaign="1" copy="1" network="1" sector="0" 
> ecpmi="1000">AdvertTitleAdvertSummaryClickThroughURL
> http://feed.domain.net/click.ashx?sys=aaae=sBG08dZWyRwhRESxvC6tX6WzJWV8BdmTrS%2bTR5ER3iawNpt8CrWuXiUojalDVLd%2b0mecpq8jjsCmDIKOgWIVyMkLLh4%2f6XAsMfxC535sUJC%2fb2agNsARWsEYXrPgvu%2b9sBPCJWM6YQUuN8PWqP1k8MTFpq0XwVGgGcSs03i6VRu61q9oC6JSVpARh44Sx10YOnY1Clsm24833w3TAYm0QqPDOVLMMKqrQErT0n66okBFchacKl2EhZy64VnpzJI4xJRaL%2bkavtFnsX18b6bPl0PWJadPPz%2fZ%2fe7cpS7U7qiT74wIIPwBNkoxCBLO7xqT4E8t62OSIRpUTgMxYY4Z9REWoGZYBq%2fyox8YGTV509gknMpdzQfY9uBKEj5BZgNmzkzozVelNi0agbsdLEbWhQ%3d%3d
> StandardText`
>
> func main() {
> r := MMXML_HostProperties {}
> err := xml.Unmarshal([]byte(s), )
> if err != nil {
> panic(err)
> }
> fmt.Printf("%+v", r)
> }
>
> playground: https://play.golang.org/p/BbsrKYFPj5-
>
> Basically I want to get the elements within "advert" tag, however it 
> always returns empty. Any ideas why?
>
> As for the "bid" attribute within "adverts" tag, what would be the 
> appropiate approach?
>
> Thanks in advance.
>
>
>

-- 
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] Re: Help with XML parsing

[C Banning]

https://play.golang.org/p/0Zl9J51yDiF

On Tuesday, April 3, 2018 at 4:36:34 PM UTC-6, XXX ZZZ wrote:
>
> Thanks a lot for your reply, any particular reason of why "response" 
> should be left out? given that is still a parent tag.
>
> As for getting the bid attribute, any idea how to do that? 
>
> El martes, 3 de abril de 2018, 19:29:41 (UTC-3), C Banning escribió:
>>
>> https://play.golang.org/p/MwpdBwvRnUP
>>
>> On Tuesday, April 3, 2018 at 2:47:49 PM UTC-6, XXX ZZZ wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to parse an XML with golang but I'm having a hard time 
>>> creating a parser for the string, in fact I couldn't even get an output 
>>> using interface{}.
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "encoding/xml"
>>> )
>>>
>>>
>>> type MMXML_Listing struct {
>>> Original_title string `xml:"title"`
>>> Original_desc   string `xml:"description"`
>>> Original_domain   string `xml:"displayurl"`
>>> Original_URL   string `xml:"clickurl"`
>>> }
>>>
>>> type MMXML_HostProperties struct {
>>> Tags[]MMXML_Listing`xml:"response>adverts>advert"`
>>> }
>>> const s = `>> results="1" search="806848020741095496" query="whatsapp" country="XX" 
>>> platform="zzz" currency="USD" guid="FP.66.66.66.61">>> provider="0" bid="1" campaign="1" copy="1" network="1" sector="0" 
>>> ecpmi="1000">AdvertTitleAdvertSummaryClickThroughURL
>>> http://feed.domain.net/click.ashx?sys=aaae=sBG08dZWyRwhRESxvC6tX6WzJWV8BdmTrS%2bTR5ER3iawNpt8CrWuXiUojalDVLd%2b0mecpq8jjsCmDIKOgWIVyMkLLh4%2f6XAsMfxC535sUJC%2fb2agNsARWsEYXrPgvu%2b9sBPCJWM6YQUuN8PWqP1k8MTFpq0XwVGgGcSs03i6VRu61q9oC6JSVpARh44Sx10YOnY1Clsm24833w3TAYm0QqPDOVLMMKqrQErT0n66okBFchacKl2EhZy64VnpzJI4xJRaL%2bkavtFnsX18b6bPl0PWJadPPz%2fZ%2fe7cpS7U7qiT74wIIPwBNkoxCBLO7xqT4E8t62OSIRpUTgMxYY4Z9REWoGZYBq%2fyox8YGTV509gknMpdzQfY9uBKEj5BZgNmzkzozVelNi0agbsdLEbWhQ%3d%3d
>>> StandardText`
>>>
>>> func main() {
>>> r := MMXML_HostProperties {}
>>> err := xml.Unmarshal([]byte(s), )
>>> if err != nil {
>>> panic(err)
>>> }
>>> fmt.Printf("%+v", r)
>>> }
>>>
>>> playground: https://play.golang.org/p/BbsrKYFPj5-
>>>
>>> Basically I want to get the elements within "advert" tag, however it 
>>> always returns empty. Any ideas why?
>>>
>>> As for the "bid" attribute within "adverts" tag, what would be the 
>>> appropiate approach?
>>>
>>> Thanks in advance.
>>>
>>>
>>>

-- 
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] Re: Help with XML parsing

[XXX ZZZ]

Thanks a lot for your reply, any particular reason of why "response" should 
be left out? given that is still a parent tag.

As for getting the bid attribute, any idea how to do that? 

El martes, 3 de abril de 2018, 19:29:41 (UTC-3), C Banning escribió:
>
> https://play.golang.org/p/MwpdBwvRnUP
>
> On Tuesday, April 3, 2018 at 2:47:49 PM UTC-6, XXX ZZZ wrote:
>>
>> Hello,
>>
>> I'm trying to parse an XML with golang but I'm having a hard time 
>> creating a parser for the string, in fact I couldn't even get an output 
>> using interface{}.
>>
>> package main
>>
>> import (
>> "fmt"
>> "encoding/xml"
>> )
>>
>>
>> type MMXML_Listing struct {
>> Original_title string `xml:"title"`
>> Original_desc   string `xml:"description"`
>> Original_domain   string `xml:"displayurl"`
>> Original_URL   string `xml:"clickurl"`
>> }
>>
>> type MMXML_HostProperties struct {
>> Tags[]MMXML_Listing`xml:"response>adverts>advert"`
>> }
>> const s = `> results="1" search="806848020741095496" query="whatsapp" country="XX" 
>> platform="zzz" currency="USD" guid="FP.66.66.66.61">> provider="0" bid="1" campaign="1" copy="1" network="1" sector="0" 
>> ecpmi="1000">AdvertTitleAdvertSummaryClickThroughURL
>> http://feed.domain.net/click.ashx?sys=aaae=sBG08dZWyRwhRESxvC6tX6WzJWV8BdmTrS%2bTR5ER3iawNpt8CrWuXiUojalDVLd%2b0mecpq8jjsCmDIKOgWIVyMkLLh4%2f6XAsMfxC535sUJC%2fb2agNsARWsEYXrPgvu%2b9sBPCJWM6YQUuN8PWqP1k8MTFpq0XwVGgGcSs03i6VRu61q9oC6JSVpARh44Sx10YOnY1Clsm24833w3TAYm0QqPDOVLMMKqrQErT0n66okBFchacKl2EhZy64VnpzJI4xJRaL%2bkavtFnsX18b6bPl0PWJadPPz%2fZ%2fe7cpS7U7qiT74wIIPwBNkoxCBLO7xqT4E8t62OSIRpUTgMxYY4Z9REWoGZYBq%2fyox8YGTV509gknMpdzQfY9uBKEj5BZgNmzkzozVelNi0agbsdLEbWhQ%3d%3d
>> StandardText`
>>
>> func main() {
>> r := MMXML_HostProperties {}
>> err := xml.Unmarshal([]byte(s), )
>> if err != nil {
>> panic(err)
>> }
>> fmt.Printf("%+v", r)
>> }
>>
>> playground: https://play.golang.org/p/BbsrKYFPj5-
>>
>> Basically I want to get the elements within "advert" tag, however it 
>> always returns empty. Any ideas why?
>>
>> As for the "bid" attribute within "adverts" tag, what would be the 
>> appropiate approach?
>>
>> Thanks in advance.
>>
>>
>>

-- 
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] Re: Help with XML parsing

[C Banning]

https://play.golang.org/p/MwpdBwvRnUP

On Tuesday, April 3, 2018 at 2:47:49 PM UTC-6, XXX ZZZ wrote:
>
> Hello,
>
> I'm trying to parse an XML with golang but I'm having a hard time creating 
> a parser for the string, in fact I couldn't even get an output using 
> interface{}.
>
> package main
>
> import (
> "fmt"
> "encoding/xml"
> )
>
>
> type MMXML_Listing struct {
> Original_title string `xml:"title"`
> Original_desc   string `xml:"description"`
> Original_domain   string `xml:"displayurl"`
> Original_URL   string `xml:"clickurl"`
> }
>
> type MMXML_HostProperties struct {
> Tags[]MMXML_Listing`xml:"response>adverts>advert"`
> }
> const s = ` results="1" search="806848020741095496" query="whatsapp" country="XX" 
> platform="zzz" currency="USD" guid="FP.66.66.66.61"> provider="0" bid="1" campaign="1" copy="1" network="1" sector="0" 
> ecpmi="1000">AdvertTitleAdvertSummaryClickThroughURL
> http://feed.domain.net/click.ashx?sys=aaae=sBG08dZWyRwhRESxvC6tX6WzJWV8BdmTrS%2bTR5ER3iawNpt8CrWuXiUojalDVLd%2b0mecpq8jjsCmDIKOgWIVyMkLLh4%2f6XAsMfxC535sUJC%2fb2agNsARWsEYXrPgvu%2b9sBPCJWM6YQUuN8PWqP1k8MTFpq0XwVGgGcSs03i6VRu61q9oC6JSVpARh44Sx10YOnY1Clsm24833w3TAYm0QqPDOVLMMKqrQErT0n66okBFchacKl2EhZy64VnpzJI4xJRaL%2bkavtFnsX18b6bPl0PWJadPPz%2fZ%2fe7cpS7U7qiT74wIIPwBNkoxCBLO7xqT4E8t62OSIRpUTgMxYY4Z9REWoGZYBq%2fyox8YGTV509gknMpdzQfY9uBKEj5BZgNmzkzozVelNi0agbsdLEbWhQ%3d%3d
> StandardText`
>
> func main() {
> r := MMXML_HostProperties {}
> err := xml.Unmarshal([]byte(s), )
> if err != nil {
> panic(err)
> }
> fmt.Printf("%+v", r)
> }
>
> playground: https://play.golang.org/p/BbsrKYFPj5-
>
> Basically I want to get the elements within "advert" tag, however it 
> always returns empty. Any ideas why?
>
> As for the "bid" attribute within "adverts" tag, what would be the 
> appropiate approach?
>
> Thanks in advance.
>
>
>

-- 
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] Re: Scheduler discrepancy between Linux and OS X with Gosched()

[Steven Hartland]

What I found interesting is with this code run with raw on FreeBSD takes 
~1s, however running via truss to see what happening with the syscalls 
it takes only ~83ms e.g.


> ./tst
2018/04/03 21:53:28 Finished in 998.77123ms.
> truss -o t.txt ./tst
2018/04/03 21:53:31 Finished in 83.14988ms.

This only seems to effect really small duration's, time.Millisecond 
isn't effected, which is perplexing.


On 03/04/2018 21:24, jake6...@gmail.com wrote:
For what it is worth, when I run your new code (without channels) on 
windows it takes consistently 1 second. On Linux it takes variably 
between 400ms and 1.5 seconds. Both running go 1.10. But, on my 
systems, this seems to be actually measuring |time.Sleep()|. Removing 
the call to |spin()| and the second |runtime.Gosched() |results in the 
same times:


|
package main

import (
    "log"
    "runtime"
    "time"
)

func main() {
    runtime.GOMAXPROCS(1)

    t0 := time.Now()
    for i := 0; i < 1000; i++ {
        time.Sleep(1 * time.Microsecond)
    }

    log.Printf("Finished in %v.", time.Since(t0))
}
|

I can not speak for your original example, but in this one I would be 
looking to |time.Sleep()|.


- Jake


On Tuesday, April 3, 2018 at 2:12:40 PM UTC-4, brianbl...@gmail.com 
wrote:


Hi Dave, thanks for the reply!

It makes sense that the send c <- 0 is not guaranteed to transfer
control to the receiving goroutine. But is it not guaranteed that
runtime.Gosched() will at least check if another goroutine is
runnable? I thought that was roughly the point of runtime.Gosched().

I see what you're saying in that when the second goroutine calls
Gosched, the sleep period may not be finished. But this will only
waste another 100 microseconds by design (not 100 milliseconds),
so it seems like control flow should return to the main goroutine
approximately when the sleep call finishes.

I created a simpler example, that doesn't use channels and avoids
the work length ambiguity, posted below. Now the secondary
goroutine just does an infinite loop of runtime.Gosched(). It
should be instantaneous to run (and is on my Mac), but it takes
almost exactly 5 seconds on Ubuntu, suggesting that there is some
fixed 5 millisecond delay on Gosched(). And adding a print above
spin's Gosched makes it instantaneous.

Thanks for your patience! I'm working on an application where the
~5ms Gosched delay is meaningful and I am very curious to figure
out what's going on here.
|
package main

import (
    "log"
    "runtime"
    "time"
)

func spin() {
    for {
        runtime.Gosched()
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go spin()

    t0 := time.Now()
    for i := 0; i < 1000; i++ {
        time.Sleep(10 * time.Microsecond)

        runtime.Gosched()
    }

    log.Printf("Finished in %v.", time.Since(t0))
}
|


On Tuesday, April 3, 2018 at 12:56:49 AM UTC-4,
brianbl...@gmail.com wrote:

I've run into some mysterious behavior, where Gosched() works
as expected in Mac OS X, but only works as expected in Ubuntu
if I put a logging statement before it.

I originally posted this on Stack Overflow but was directed
here. Post:

https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x



Any help would be greatly appreciated! Very curious what's
going on here, as this behavior came up while I was trying to
write a websocket broadcast server. Here's a minimal setup
that reproduces the behavior:

The main goroutine sleeps for 1000 periods of 1ms, and after
each sleep pushes a dummy message onto another goroutine via a
channel. The second goroutine listens for new messages, and
every time it gets one it does 10ms of work. So without any
|runtime.Gosched()| calls, the program will take 10 seconds to
run.

When I add periodic |runtime.Gosched()| calls in the second
goroutine, as expected the program runtime shrinks down to 1
second on my Mac. However, when I try running the same program
on Ubuntu, it still takes 10 seconds. I made sure to set
|runtime.GOMAXPROCS(1)| in both cases.

Here's where it gets really strange: if I just add a logging
statement before the the |runtime.Gosched()| calls, then
suddenly the program runs in the expected 1 second on Ubuntu
as well.


|packagemain import("time""log""runtime")func doWork(c chan
int){for{<-c // This outer loop will take ~10ms.forj :=0;j
<100;j++{// The following block of CPU work takes ~100
microsecondsfori :=0;i <30;i++{_ =i *17}// Somehow this
print statement saves the day in

[go-nuts] Help with XML parsing

[XXX ZZZ]

Hello,

I'm trying to parse an XML with golang but I'm having a hard time creating 
a parser for the string, in fact I couldn't even get an output using 
interface{}.

package main

import (
"fmt"
"encoding/xml"
)


type MMXML_Listing struct {
Original_title string `xml:"title"`
Original_desc   string `xml:"description"`
Original_domain   string `xml:"displayurl"`
Original_URL   string `xml:"clickurl"`
}

type MMXML_HostProperties struct {
Tags[]MMXML_Listing`xml:"response>adverts>advert"`
}
const s = `AdvertTitleAdvertSummaryClickThroughURLhttp://feed.domain.net/click.ashx?sys=aaae=sBG08dZWyRwhRESxvC6tX6WzJWV8BdmTrS%2bTR5ER3iawNpt8CrWuXiUojalDVLd%2b0mecpq8jjsCmDIKOgWIVyMkLLh4%2f6XAsMfxC535sUJC%2fb2agNsARWsEYXrPgvu%2b9sBPCJWM6YQUuN8PWqP1k8MTFpq0XwVGgGcSs03i6VRu61q9oC6JSVpARh44Sx10YOnY1Clsm24833w3TAYm0QqPDOVLMMKqrQErT0n66okBFchacKl2EhZy64VnpzJI4xJRaL%2bkavtFnsX18b6bPl0PWJadPPz%2fZ%2fe7cpS7U7qiT74wIIPwBNkoxCBLO7xqT4E8t62OSIRpUTgMxYY4Z9REWoGZYBq%2fyox8YGTV509gknMpdzQfY9uBKEj5BZgNmzkzozVelNi0agbsdLEbWhQ%3d%3dStandardText`

func main() {
r := MMXML_HostProperties {}
err := xml.Unmarshal([]byte(s), )
if err != nil {
panic(err)
}
fmt.Printf("%+v", r)
}

playground: https://play.golang.org/p/BbsrKYFPj5-

Basically I want to get the elements within "advert" tag, however it always 
returns empty. Any ideas why?

As for the "bid" attribute within "adverts" tag, what would be the 
appropiate approach?

Thanks in advance.


-- 
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] Re: Scheduler discrepancy between Linux and OS X with Gosched()

[jake6502]

For what it is worth, when I run your new code (without channels) on 
windows it takes consistently 1 second. On Linux it takes variably between 
400ms and 1.5 seconds. Both running go 1.10. But, on my systems, this seems 
to be actually measuring time.Sleep(). Removing the call to spin() and the 
second runtime.Gosched() results in the same times:

package main

import (
"log"
"runtime"
"time"
)

func main() {
runtime.GOMAXPROCS(1)

t0 := time.Now()
for i := 0; i < 1000; i++ {
time.Sleep(1 * time.Microsecond)
}

log.Printf("Finished in %v.", time.Since(t0))
}

I can not speak for your original example, but in this one I would be 
looking to time.Sleep(). 

- Jake


On Tuesday, April 3, 2018 at 2:12:40 PM UTC-4, brianbl...@gmail.com wrote:
>
> Hi Dave, thanks for the reply!
>
> It makes sense that the send c <- 0 is not guaranteed to transfer control 
> to the receiving goroutine. But is it not guaranteed that runtime.Gosched() 
> will at least check if another goroutine is runnable? I thought that was 
> roughly the point of runtime.Gosched(). 
>
> I see what you're saying in that when the second goroutine calls Gosched, 
> the sleep period may not be finished. But this will only waste another 100 
> microseconds by design (not 100 milliseconds), so it seems like control 
> flow should return to the main goroutine approximately when the sleep call 
> finishes.
>
> I created a simpler example, that doesn't use channels and avoids the work 
> length ambiguity, posted below. Now the secondary goroutine just does an 
> infinite loop of runtime.Gosched(). It should be instantaneous to run (and 
> is on my Mac), but it takes almost exactly 5 seconds on Ubuntu, suggesting 
> that there is some fixed 5 millisecond delay on Gosched(). And adding a 
> print above spin's Gosched makes it instantaneous.
>
> Thanks for your patience! I'm working on an application where the ~5ms 
> Gosched delay is meaningful and I am very curious to figure out what's 
> going on here. 
> package main
>
> import (
> "log"
> "runtime"
> "time"
> )
>
> func spin() {
> for {
> runtime.Gosched()
> }
> }
>
> func main() {
> runtime.GOMAXPROCS(1)
> go spin()
>
> t0 := time.Now()
> for i := 0; i < 1000; i++ {
> time.Sleep(10 * time.Microsecond)
>
> runtime.Gosched()
> }
>
> log.Printf("Finished in %v.", time.Since(t0))
> }
>
>
> On Tuesday, April 3, 2018 at 12:56:49 AM UTC-4, brianbl...@gmail.com 
> wrote:
>>
>> I've run into some mysterious behavior, where Gosched() works as expected 
>> in Mac OS X, but only works as expected in Ubuntu if I put a logging 
>> statement before it.
>>
>> I originally posted this on Stack Overflow but was directed here. Post: 
>> https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x
>>
>> Any help would be greatly appreciated! Very curious what's going on here, 
>> as this behavior came up while I was trying to write a websocket broadcast 
>> server. Here's a minimal setup that reproduces the behavior:
>>
>> The main goroutine sleeps for 1000 periods of 1ms, and after each sleep 
>> pushes a dummy message onto another goroutine via a channel. The second 
>> goroutine listens for new messages, and every time it gets one it does 10ms 
>> of work. So without any runtime.Gosched() calls, the program will take 
>> 10 seconds to run.
>>
>> When I add periodic runtime.Gosched() calls in the second goroutine, as 
>> expected the program runtime shrinks down to 1 second on my Mac. However, 
>> when I try running the same program on Ubuntu, it still takes 10 seconds. I 
>> made sure to set runtime.GOMAXPROCS(1) in both cases.
>>
>> Here's where it gets really strange: if I just add a logging statement 
>> before the the runtime.Gosched() calls, then suddenly the program runs 
>> in the expected 1 second on Ubuntu as well.
>>
>>
>> package main
>> import (
>> "time"
>> "log"
>> "runtime")
>>
>> func doWork(c chan int) {
>> for {
>> <-c
>>
>> // This outer loop will take ~10ms.
>> for j := 0; j < 100 ; j++ {
>> // The following block of CPU work takes ~100 microseconds
>> for i := 0; i < 30; i++ {
>> _ = i * 17
>> }
>> // Somehow this print statement saves the day in Ubuntu
>> log.Printf("donkey")
>> runtime.Gosched()
>> }
>> }}
>>
>> func main() {
>> runtime.GOMAXPROCS(1)
>> c := make(chan int, 1000)
>> go doWork(c)
>>
>> start := time.Now().UnixNano()
>> for i := 0; i < 1000; i++ {
>> time.Sleep(1 * time.Millisecond)
>>
>> // Queue up 10ms of work in the other goroutine, which will backlog
>> // this goroutine without runtime.Gosched() calls.
>> c <- 0
>> }
>>
>> // Whole program should take about 1 second to run if the Gosched() 
>> calls 
>> // work, otherwise 10 seconds.
>> 

[go-nuts] Re: Scheduler discrepancy between Linux and OS X with Gosched()

[brianblakewong]

Hi Dave, thanks for the reply!

It makes sense that the send c <- 0 is not guaranteed to transfer control 
to the receiving goroutine. But is it not guaranteed that runtime.Gosched() 
will at least check if another goroutine is runnable? I thought that was 
roughly the point of runtime.Gosched(). 

I see what you're saying in that when the second goroutine calls Gosched, 
the sleep period may not be finished. But this will only waste another 100 
microseconds by design (not 100 milliseconds), so it seems like control 
flow should return to the main goroutine approximately when the sleep call 
finishes.

I created a simpler example, that doesn't use channels and avoids the work 
length ambiguity, posted below. Now the secondary goroutine just does an 
infinite loop of runtime.Gosched(). It should be instantaneous to run (and 
is on my Mac), but it takes almost exactly 5 seconds on Ubuntu, suggesting 
that there is some fixed 5 millisecond delay on Gosched(). And adding a 
print above spin's Gosched makes it instantaneous.

Thanks for your patience! I'm working on an application where the ~5ms 
Gosched delay is meaningful and I am very curious to figure out what's 
going on here. 
package main

import (
"log"
"runtime"
"time"
)

func spin() {
for {
runtime.Gosched()
}
}

func main() {
runtime.GOMAXPROCS(1)
go spin()

t0 := time.Now()
for i := 0; i < 1000; i++ {
time.Sleep(10 * time.Microsecond)

runtime.Gosched()
}

log.Printf("Finished in %v.", time.Since(t0))
}


On Tuesday, April 3, 2018 at 12:56:49 AM UTC-4, brianbl...@gmail.com wrote:
>
> I've run into some mysterious behavior, where Gosched() works as expected 
> in Mac OS X, but only works as expected in Ubuntu if I put a logging 
> statement before it.
>
> I originally posted this on Stack Overflow but was directed here. Post: 
> https://stackoverflow.com/questions/49617451/golang-scheduler-mystery-linux-vs-mac-os-x
>
> Any help would be greatly appreciated! Very curious what's going on here, 
> as this behavior came up while I was trying to write a websocket broadcast 
> server. Here's a minimal setup that reproduces the behavior:
>
> The main goroutine sleeps for 1000 periods of 1ms, and after each sleep 
> pushes a dummy message onto another goroutine via a channel. The second 
> goroutine listens for new messages, and every time it gets one it does 10ms 
> of work. So without any runtime.Gosched() calls, the program will take 10 
> seconds to run.
>
> When I add periodic runtime.Gosched() calls in the second goroutine, as 
> expected the program runtime shrinks down to 1 second on my Mac. However, 
> when I try running the same program on Ubuntu, it still takes 10 seconds. I 
> made sure to set runtime.GOMAXPROCS(1) in both cases.
>
> Here's where it gets really strange: if I just add a logging statement 
> before the the runtime.Gosched() calls, then suddenly the program runs in 
> the expected 1 second on Ubuntu as well.
>
>
> package main
> import (
> "time"
> "log"
> "runtime")
>
> func doWork(c chan int) {
> for {
> <-c
>
> // This outer loop will take ~10ms.
> for j := 0; j < 100 ; j++ {
> // The following block of CPU work takes ~100 microseconds
> for i := 0; i < 30; i++ {
> _ = i * 17
> }
> // Somehow this print statement saves the day in Ubuntu
> log.Printf("donkey")
> runtime.Gosched()
> }
> }}
>
> func main() {
> runtime.GOMAXPROCS(1)
> c := make(chan int, 1000)
> go doWork(c)
>
> start := time.Now().UnixNano()
> for i := 0; i < 1000; i++ {
> time.Sleep(1 * time.Millisecond)
>
> // Queue up 10ms of work in the other goroutine, which will backlog
> // this goroutine without runtime.Gosched() calls.
> c <- 0
> }
>
> // Whole program should take about 1 second to run if the Gosched() calls 
> // work, otherwise 10 seconds.
> log.Printf("Finished in %f seconds.", float64(time.Now().UnixNano() - 
> start) / 1e9)}
>
>
>

-- 
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] [ANN] A Minecraft like game written in go

[樊冰心]

Hi,

I wrote this project when I was learning OpenGL. Although I am not an 
expert in the game field, writing games with go is cool.
Github repository: https://github.com/icexin/gocraft

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.

[go-nuts] Re: blocking profiler

[Dave Cheney]

I’ve not seen that problem before. I’d hazard a guess that it’s an incorrect go 
installation. Don’t set goroot, basically ever. But it’s just a guess. 

Are you able to create a stand alone program that demonstrates the issue with 
the profile? Please consider raising a bug, golang.org/issue/new

-- 
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] Re: API fixes for sync.Mutex and friends?

[matthewjuran]

The pointer logic is a hard part of Go. I don’t know how much performance 
is gained by worrying about it, but I’ve learned to like having 
function/method call argument copies in some cases.

I think becoming an expert on when to pick a pointer or not is a 
fundamental part of Go programming. This shouldn’t be a subtle issue and 
working around it invites poor code.

Matt

On Monday, April 2, 2018 at 6:37:36 PM UTC-5, Andrew Pennebaker wrote:
>
> Some Go types like sync.Mutex have a subtle API issue, where the objects 
> really shouldn't be copied or passed around into different function calls, 
> e.g. to a goroutine worker. However, this is not enforced by the current 
> API, but merely mentioned in the documentation, which is easily ignored.
>
> Is there a way to better protect these types, so that users can't 
> accidentally copy and corrupt them? Maybe a linter or the Go compiler could 
> check for these types being passed in non-pointer form to function calls. I 
> wonder if this problem still appears in Rust, or if the borrow checker 
> could model this API distinction more safely and automatically?
>

-- 
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] corrupt stack?

[matthewjuran]

Does the program use cgo?

Matt

On Monday, April 2, 2018 at 6:48:14 PM UTC-5, Erik Quanstrom wrote:
>
> after upgrading to 1.9 (50% reduction) and finding a data race we didn't 
> see in testing,
> we're still hunting down about 1 crash per 67 million hours of runtime.
>
> needless to say, the economical thing to do is to ignore the problem, but 
> it sure bugs (!)
> me.  the correct number of crashes is 0.
>
> - erik
>
> On Tuesday, December 5, 2017 at 4:37:46 PM UTC-8, Erik Quanstrom wrote:
>>
>> the failure rate is high enough to be motivating.  :-)  i now have go 1.9 
>> working for
>> production builds.  i will report back with results as soon as i have 
>> them.
>>
>> - erik
>>
>> On Monday, December 4, 2017 at 6:16:29 PM UTC-8, Ian Lance Taylor wrote:
>>>
>>> On Sun, Dec 3, 2017 at 6:42 PM,   wrote: 
>>> > 
>>> > i'm running go 1.8.3 on linux.  about 1 in ~10 billion calls (spread 
>>> across 
>>> > many machines), i get 
>>> > a backtrace that looks like the following: 
>>> > 
>>> > panic: runtime error: invalid memory address or nil pointer 
>>> dereference 
>>> > [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 
>>> pc=0x4c3406] 
>>> > goroutine 441026 [running]: 
>>> > bufio.(*Reader).ReadSlice(0x0, 0xa, 0x30, 0xc420256ec8, 0xc4201b9ef0, 
>>> > 0xc420315580, 0x0) 
>>> > #011/usr/lib/golang/src/bufio/bufio.go:316 +0x26 
>>> > bufio.(*Reader).ReadLine(0x0, 0xa1f378, 0x30, 0xc4201b9ef0, 0x30, 
>>> > 0xc4201b9ef0, 0x30) 
>>> > #011/usr/lib/golang/src/bufio/bufio.go:367 +0x37 
>>> > fakexpkg.(*Xpkg).tableParse(0x, 0x0, 0x0) 
>>> > <- HERE 
>>> > #011/builddir/build/BUILD/posthoc-1.1/src/fakexpkg/xpkg.go:175 +0x86 
>>> > created by fakexpkg.(*Xpkg).List 
>>> > #011/builddir/build/BUILD/posthoc-1.1/src/fakexpkg/xpkg.go:225 +0x2ac 
>>> > 
>>> > the code calling tableparse looks something like this.  no references 
>>> to 
>>> > anything 
>>> > table at the end are kept in other places. 
>>> > 
>>> > ret := make(chan []*Info, 1) 
>>> > go x.tableParse(bufio.NewReader(outpipe), ret) 
>>> > table := <-ret 
>>> > 
>>> > other c programs that i run on these same machines do not core dump at 
>>> all. 
>>> > 
>>> > since there is no use of the unsafe package anywhere in this program, 
>>> i'm 
>>> > confused as to 
>>> > how the Xpkg receiver could be -1 unless something has gone wrong with 
>>> the 
>>> > runtime. 
>>> > i feel like i must be missing something though, since it's never the 
>>> layer 
>>> > below. 
>>> > 
>>> > does anyone have any idea what's going on here, or some hints on 
>>> debugging 
>>> > this? 
>>>
>>> Assuming that the race detector doesn't report any problems, this is a 
>>> strange example of memory corruption: not only is the receiver pointer 
>>> invalid, the two arguments to the function are nil even though the 
>>> code fragment shows that that is not possible.  From your description 
>>> the problem is very very rare.  How much time and energy do you have 
>>> for experimentation?  If you have some, the first step is certainly to 
>>> try using Go 1.9, as various bugs have been fixed.  If it still 
>>> happens the same way, the next step is to try to reduce the program to 
>>> a self-contained example that you can share.  At a guess given that 
>>> three words appear to be corrupt, it may have something to do with the 
>>> way that goroutine arguments are saved.  I don't see any way that 
>>> could fail, but then this is a very rare problem. 
>>>
>>> Ian 
>>>
>>

-- 
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] Re: blocking profiler

[sothy shan]

On Saturday, March 31, 2018 at 12:15:34 AM UTC+2, Dave Cheney wrote:
>
> It looks like you’re stopping the block profile immediately after starting 
> it. 
>
> Try github.com/pkg/profile which will take care of the plumbing for you. 


Thanks Dave for pointing your code.
After viewing your code, I corrected my code.


 f,err :=os.Create("/tmp/test_blocking.prof")
  if err != nil  {
 log.WithError(err).Fatal("creation of blocking 
profiler file is failed" )
  }
  runtime.SetBlockProfileRate(1)
  
  defer func() {
 if err := pprof.Lookup("block").WriteTo(f,0); err 
!=nil {
log.WithError(err).Fatal("blocking profiler 
statistic collecition initialization failed")
 }
   
 f.Close()
 runtime.SetBlockProfileRate(0)
  }()

Now I am getting block profile information. When I run the go tool pprof, I 
got nothing in the result. Why?



go tool pprof test_blocking.prof 
Main binary filename not available.
Type: delay
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top30
Showing nodes accounting for 13.16mins, 100% of 13.16mins total
  flat  flat%   sum%cum   cum%
 13.16mins   100%   100%  13.16mins   100%  



-- 
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] API fixes for sync.Mutex and friends?

[Steven Hartland]

The various meta linters pick this up.

I would highly recommend using: 
https://github.com/alecthomas/gometalinter to improve the quality of 
code, for this and other issues not picked up by the standard tool chain.


    Regards
    Steve

On 03/04/2018 00:37, Andrew Pennebaker wrote:
Some Go types like sync.Mutex have a subtle API issue, where the 
objects really shouldn't be copied or passed around into different 
function calls, e.g. to a goroutine worker. However, this is not 
enforced by the current API, but merely mentioned in the 
documentation, which is easily ignored.


Is there a way to better protect these types, so that users can't 
accidentally copy and corrupt them? Maybe a linter or the Go compiler 
could check for these types being passed in non-pointer form to 
function calls. I wonder if this problem still appears in Rust, or if 
the borrow checker could model this API distinction more safely and 
automatically?

--
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.