Re: [go-nuts] Connection Refused while scraping the data

[Kurtis Rader]

On Fri, Mar 6, 2020 at 8:21 PM Kuldeep Avsar 
wrote:

> I am trying to Scrape the Job Titles one by one from the Indeed.co.in website
>
> but it through me connection refused problem while I am visiting to the 
> particular jobs Title
>
> categories page and trying to take response back from the page but It's shows 
> error on that time.
>
> please help me out to solve this problem i am tried to solve this but this 
> not solved. Please help.
>
> 2020/03/07 09:08:41 Error to Connect with Indeed Jobs Category Page.Get 
> https://indeed.co.in/browsejobs/Engineering: dial tcp 169.44.165.69:443: 
> connect: connection refuse
>
>
The web site you are accessing thinks you are executing a DDOS attack or
are otherwise violating their terms of service. This has nothing to do with
the Go language. You need to rate limit your requests of that site.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD93h-w0-X78DYNSUTRRNM8GJBcZKFjxoG_Y2Nejn%3DVRZA%40mail.gmail.com.

[go-nuts] Re: Is the result of FindStringSubmatch correct?

[bomin]

Got it, thanks.

在 2020年3月2日星期一 UTC+8下午7:39:28，Brian Candler写道：
>
> Or closer to your original code, FindAllStringSubmatch 
> .
> https://play.golang.org/p/Tiva8X425k3
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c1904e50-aec5-4736-94b1-5283b721069d%40googlegroups.com.

Re: [go-nuts] interaction between runtime scheduler and Cgo calls

[Dan Kortschak]

Thanks, Ian.

On Fri, 2020-03-06 at 14:01 -0800, Ian Lance Taylor wrote:
> On Fri, Mar 6, 2020 at 1:40 PM Dan Kortschak 
> wrote:
> > 
> > This sort of follows on from the EINTR discussion a while back, but
> > was
> > prompted by a claim in the gophers #general slack channel that "the
> > Go
> > scheduler will actively try to interrupt CGO calls that take too
> > long"[1].
> > 
> > This doesn't seem right to me, but I wanted to confirm from people
> > who
> > know (also is there any documentation about the behaviour of the
> > new
> > pre-emptive scheduler?).
> 
> There is a sense in which it is right.  When a cgo call starts it has
> a P attached to it (in the scheduler, a P is a virtual processor;
> there are exactly GOMAXPROCS P's at all times).  If the cgo call
> completes quickly, it will simply carry on with the same P.  When the
> system monitoring thread wakes up, it will check each P to see if it
> has been waiting for a cgo call to complete for more than a scheduler
> tick (20 microseconds, more or less).  If so, the P will be stolen
> and
> some other M (operating system thread) will be woken up to start
> using
> the P and running Go code.  When the cgo call completes, the
> goroutine
> will see that it no longer has a P, and will go to sleep waiting for
> a
> P to become available (more or less as though the goroutine called
> runtime.Gosched).
> 
> So in that sense, cgo calls will be interrupted: the P will be
> removed
> and reassigned to do other work.
> 
> However, the actual C code running on the M (operating system thread)
> will not be affected.  And the G (goroutine) will of course remain
> asleep waiting for the cgo call to complete.
> 
> (This is all a description of the current 1.14 scheduler, and it may
> be different in other releases.)
> 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e9455c1df7dc04a27c580e83b1ec7536447b3c3e.camel%40kortschak.io.

Re: [go-nuts] interaction between runtime scheduler and Cgo calls

[Ian Lance Taylor]

On Fri, Mar 6, 2020 at 1:40 PM Dan Kortschak  wrote:
>
> This sort of follows on from the EINTR discussion a while back, but was
> prompted by a claim in the gophers #general slack channel that "the Go
> scheduler will actively try to interrupt CGO calls that take too
> long"[1].
>
> This doesn't seem right to me, but I wanted to confirm from people who
> know (also is there any documentation about the behaviour of the new
> pre-emptive scheduler?).

There is a sense in which it is right.  When a cgo call starts it has
a P attached to it (in the scheduler, a P is a virtual processor;
there are exactly GOMAXPROCS P's at all times).  If the cgo call
completes quickly, it will simply carry on with the same P.  When the
system monitoring thread wakes up, it will check each P to see if it
has been waiting for a cgo call to complete for more than a scheduler
tick (20 microseconds, more or less).  If so, the P will be stolen and
some other M (operating system thread) will be woken up to start using
the P and running Go code.  When the cgo call completes, the goroutine
will see that it no longer has a P, and will go to sleep waiting for a
P to become available (more or less as though the goroutine called
runtime.Gosched).

So in that sense, cgo calls will be interrupted: the P will be removed
and reassigned to do other work.

However, the actual C code running on the M (operating system thread)
will not be affected.  And the G (goroutine) will of course remain
asleep waiting for the cgo call to complete.

(This is all a description of the current 1.14 scheduler, and it may
be different in other releases.)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX-omOnCgLc3GWBA0-Av7wytVh%2Boc-XLOzq_%3DBjF%3DNnGQ%40mail.gmail.com.

[go-nuts] interaction between runtime scheduler and Cgo calls

[Dan Kortschak]

This sort of follows on from the EINTR discussion a while back, but was
prompted by a claim in the gophers #general slack channel that "the Go
scheduler will actively try to interrupt CGO calls that take too
long"[1].

This doesn't seem right to me, but I wanted to confirm from people who
know (also is there any documentation about the behaviour of the new
pre-emptive scheduler?).

thanks
Dan

[1]
https://gophers.slack.com/archives/C0UKS8V9S/p158352030900?thread_ts=1583487810.024900&cid=C0UKS8V9S


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5c06438bd12fe6fa8a6da49170b1fb024ca7422b.camel%40kortschak.io.

Re: [go-nuts] Re: Memory leak or GC feature ?

[Jesper Louis Andersen]

On Fri, Mar 6, 2020 at 5:21 PM Christophe Meessen <
christophe.mees...@gmail.com> wrote:

>
>
However, it never gets back to the low level it had initially. Initial
> lowest Alloc is 146520. It then grows steadily up to 163040. Then suddenly
> drops to 156896, and grows slowly again to 163520. Then drops suddenly to
> 157376. Etc.
> So memory is indeed a little bit partially reclaimed from time to time. So
> the GC kind of works, but the GC() function doesn’t behave as I was
> expectiong.
>
>
Small fluctuations like these are somewhat expected. In a multi-core
environment, you often want to cache processor-locally. Many malloc
implementations would show the same behavior nowadays.

However, what is more likely here is that you are looking at different
snapshots when the sweep phase is being run. Once we have marked all live
data in the GC, we initiate the sweep phase to reclaim the unmarked data.
But this happens incrementally while our program is running. Thus we can
probably expect the numbers to fluctuate a small bit. Note that while your
program only allows one OS thread, the GC will happily use all your
available cores for speeding up the the GC phase. So you are also looking
at non-determinism in a concurrent environment.

You need to rely on different methods if you want to detect for memory
leaks in programs. The package "runtime/pprof" contains ways to get a
memory profile of the program, including allocations at call sites and so
on. I would probably use these tools to hunt for eventual memory leaks in
programs.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiU2Efc%3DLnH%3DTVHuUytoQnR2COSZYe8Y3PS2zdSZ-41Ajg%40mail.gmail.com.

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Dan Kortschak]

Is this helpful for addressing your issue?

On Fri, 2020-03-06 at 04:42 -0800, Warren Stephens wrote:
> Perhaps I should have referenced MIT's Scratch programming tool??? 
> "Go is not as good as Scratch" -- THAT would be popular around here I
> am sure!


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2f4306cbb210e410399c9f291085c44920808cc9.camel%40kortschak.io.

[go-nuts] Re: Changing source code in order code to be supported from older Golang versions e.g. Go 1.10

[Jake Montgomery]

On Friday, March 6, 2020 at 1:20:38 PM UTC-5, Amnon Baron Cohen wrote:
>
> Anyone who is able to put up with a 20 year old OS
> will be able to tolerate a 2 year old Go version...
>

Dimitrios' question is a perfectly legitimate one. Your response does 
nothing to actually answer the question. It also comes across as a bit 
snarky. Just a friendly reminder that the Go community strives to be 
"friendly and welcoming" to all. https://golang.org/conduct is a worthwhile 
read. 


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a94315d3-933a-49b6-a5b2-de811d1e50ca%40googlegroups.com.

[go-nuts] gomobile video for ios and android?

[oneone]

hello, looking at:

https://godoc.org/golang.org/x/mobile

I see I can draw any polygon or text or image to the screen. And with audio:

https://godoc.org/golang.org/x/mobile/exp/audio/al

I see I could play any sound I want so... my question is, is it possible to 
stream a video file and play it?

Feels like https://godoc.org/golang.org/x/mobile/exp/video 


package is missing but coming soon? Is it a fools errand to try and write 
this logic in go? Would I have to re-create some ffmpeg c logic?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9c94ed30-7072-469d-9005-e165d25a91df%40googlegroups.com.

[go-nuts] Re: Changing source code in order code to be supported from older Golang versions e.g. Go 1.10

[Amnon Baron Cohen]

Anyone who is able to put up with a 20 year old OS
will be able to tolerate a 2 year old Go version...

On Thursday, 5 March 2020 11:08:07 UTC, Dimitrios Trechas wrote:
>
> Dear colleagues,
>
> There are even now cases that a Windows XP is needed. The latest Golang 
> compiler that could target XP was 1.10.
>
> Is there anyone who had to write a source converter that could convert 
> recent Golang code to backwards compatible code (in case there is no 
> version clash/hell of different libs) ? E.g. number literals, source 
> modules to Golang 1.10?
>
>
> Thank you 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5a2710ac-1782-4e24-8c6c-0a1b31e1671b%40googlegroups.com.

Re: [go-nuts] Re: Memory leak or GC feature ?

[Jan Mercl]

On Fri, Mar 6, 2020 at 4:55 PM Christophe Meessen <
christophe.mees...@gmail.com> wrote:

> It would have been convenient for detecting memory leaks to be able to
compare memory Alloc before and after the checked task and a really
complete GC.

That's not feasible. There are _always_ other runtime-started goroutines
running during execution of a program and they may allocate memory in no
predictable pattern.

Here's a sample run with Go 1.14 on Linux/amd64 (with added time stamps).

jnml@e5-1650:~/tmp/gc> date ; ./gc
Fri Mar  6 17:10:55 CET 2020
2020-03-06 17:11:15.47671116 +0100 CET m=+20.000226110 status: memUsed:
140296 allocs: 155 numGC 0
2020-03-06 17:11:35.476718873 +0100 CET m=+40.000234661 status: memUsed:
155376 allocs: 191 numGC 1
2020-03-06 17:11:55.476670923 +0100 CET m=+60.000185942 status: memUsed:
157248 allocs: 197 numGC 2
2020-03-06 17:12:15.476638267 +0100 CET m=+80.000153357 status: memUsed:
157264 allocs: 199 numGC 3
2020-03-06 17:12:35.476746762 +0100 CET m=+100.000262341 status: memUsed:
157264 allocs: 199 numGC 4
2020-03-06 17:12:55.476724863 +0100 CET m=+120.000240581 status: memUsed:
157280 allocs: 201 numGC 5
2020-03-06 17:13:15.476737116 +0100 CET m=+140.000252973 status: memUsed:
157280 allocs: 201 numGC 6
2020-03-06 17:13:35.476650054 +0100 CET m=+160.000165143 status: memUsed:
157376 allocs: 202 numGC 7
2020-03-06 17:13:55.476609855 +0100 CET m=+180.000124805 status: memUsed:
157376 allocs: 202 numGC 8
2020-03-06 17:14:15.476707245 +0100 CET m=+200.000222544 status: memUsed:
157472 allocs: 203 numGC 9
2020-03-06 17:14:35.47665699 +0100 CET m=+220.000172009 status: memUsed:
157568 allocs: 204 numGC 10
2020-03-06 17:14:55.476618049 +0100 CET m=+240.000133068 status: memUsed:
157776 allocs: 207 numGC 11
2020-03-06 17:15:15.476615426 +0100 CET m=+260.000130515 status: memUsed:
157768 allocs: 206 numGC 12
2020-03-06 17:15:35.476601977 +0100 CET m=+280.000116926 status: memUsed:
157768 allocs: 206 numGC 13
2020-03-06 17:15:55.476594814 +0100 CET m=+300.000109833 status: memUsed:
159528 allocs: 210 numGC 14
2020-03-06 17:16:15.476613143 +0100 CET m=+320.000128162 status: memUsed:
159528 allocs: 210 numGC 15
2020-03-06 17:16:35.476656056 +0100 CET m=+340.000171146 status: memUsed:
159528 allocs: 210 numGC 16
2020-03-06 17:16:55.476664258 +0100 CET m=+360.000179278 status: memUsed:
159528 allocs: 210 numGC 17
2020-03-06 17:17:15.476620428 +0100 CET m=+380.000135448 status: memUsed:
159528 allocs: 210 numGC 18
^C
jnml@e5-1650:~/tmp/gc>

As can be seen above, eventually the allocated memory goes down and
stabilizes, as predicted by Volker.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VEE15R9Lgpaq5RYAAb%3D6nwqOAx9UCgRL9A-B%3D1Lnc7eA%40mail.gmail.com.

[go-nuts] Re: Memory leak or GC feature ?

[Christophe Meessen]

While letting the program run for a few hours I see that after some time 
the memory usage vary in saw teeth. Some of the garbage is reclaimed after 
800 calls to GC(). 

However, it never gets back to the low level it had initially. Initial 
lowest Alloc is 146520. It then grows steadily up to 163040. Then suddenly 
drops to 156896, and grows slowly again to 163520. Then drops suddenly to 
157376. Etc.
So memory is indeed a little bit partially reclaimed from time to time. So 
the GC kind of works, but the GC() function doesn’t behave as I was 
expectiong.

Le vendredi 6 mars 2020 16:55:24 UTC+1, Christophe Meessen a écrit :
>
> The documentation of the GC() function states:
>
> "GC runs a garbage collection and blocks the caller until the garbage 
> collection is complete. It may also block the entire program."
>
> Based on the documentation, I assumed that a garbage collection would be 
> really complete by calling GC. By complete I mean that no garbage is left 
> over.
>
> Apparently It’s not the case. Is it possible learn a bit more on this ? 
> Why would the GC not garbage collect everything when GC() is called ? 
>
> It would have been convenient for detecting memory leaks to be able to 
> compare memory Alloc before and after the checked task and a really 
> complete GC. 
>
>
>
>
> Le vendredi 6 mars 2020 15:26:33 UTC+1, Volker Dobler a écrit :
>>
>> This is normal behaviour and not a leak.
>> Nothing is leaking in your code (and it is generally
>> hard to leak RAM). The allocations will be reclaimed.
>>
>> V.
>>
>> On Friday, 6 March 2020 14:11:37 UTC+1, Christophe Meessen wrote:
>>>
>>> I wanted to check my program for go routine and memory leaks. In doing 
>>> so I detected what resemble a memory leak while my program was doing 
>>> nothing. 
>>>
>>> Here is a minimal program that reproduces the problem. The program 
>>> collects and prints the total number of bytes allocated and the number of 
>>> blocks. 
>>>
>>> package main
>>>
>>> import (
>>> "runtime"
>>>
>>> func main() {
>>> var m runtime.MemStats
>>> ticker := time.NewTicker(20 * time.Second)
>>> for {
>>> runtime.ReadMemStats(&m)
>>> println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees, 
>>> "numGC", m.NumGC)
>>> <-ticker.C
>>> runtime.GC()
>>> }
>>> }
>>>
>>> What I see is a slow but steady increase of memUse and allocs. The 
>>> memUse grows by 4 to 96 bytes every 40 to 60 seconds. 
>>> Is this a feature of the GC or is this a memory leak in one of the 
>>> called functions ? 
>>>
>>> Note that I use println because the "leak" is much more important when I 
>>> use fmt.Println of log.Println. I also use ticker because I was told it 
>>> would be better than time.Sleep, but I don’t see any significant difference 
>>> in the "leak" when I use one or the other. 
>>>
>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e53fb283-4b76-48f5-b5ed-319f6cf4fbb8%40googlegroups.com.

Re: [go-nuts] Re: Memory leak or GC feature ?

[Robert Engels]

Because GC costs are amortized in order to limit the effect on the performance (pauses) of the program - you should almost never manually invoke a GC.That being said, there are "memory profilers" that can detect live/dead objects in order to detect memory leaks - use them during development (and most can be used in production with some caveats).-Original Message-
From: Christophe Meessen 
Sent: Mar 6, 2020 9:55 AM
To: golang-nuts 
Subject: [go-nuts] Re: Memory leak or GC feature ?

The documentation of the GC() function states:"GC runs a garbage collection and blocks the caller until the
garbage collection is complete. It may also block the entire
program."Based on the documentation, I assumed that a garbage collection would be really complete by calling GC. By complete I mean that no garbage is left over.Apparently It’s not the case. Is it possible learn a bit more on this ? Why would the GC not garbage collect everything when GC() is called ? It would have been convenient for detecting memory leaks to be able to compare memory Alloc before and after the checked task and a really complete GC. Le vendredi 6 mars 2020 15:26:33 UTC+1, Volker Dobler a écrit :This is normal behaviour and not a leak.Nothing is leaking in your code (and it is generallyhard to leak RAM). The allocations will be reclaimed.V.On Friday, 6 March 2020 14:11:37 UTC+1, Christophe Meessen  wrote:I wanted to check my program for go routine and memory leaks. In doing so I detected what resemble a memory leak while my program was doing nothing. Here is a minimal program that reproduces the problem. The program collects and prints the total number of bytes allocated and the number of blocks. package mainimport ("runtime"func main() {var m runtime.MemStatsticker := time.NewTicker(20 * time.Second)for {runtime.ReadMemStats(&m)println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees, "numGC", m.NumGC)<-ticker.Cruntime.GC()}}What I see is a slow but steady increase of memUse and allocs. The memUse grows by 4 to 96 bytes every 40 to 60 seconds. Is this a feature of the GC or is this a memory leak in one of the called functions ? Note that I use println because the "leak" is much more important when I use fmt.Println of log.Println. I also use ticker because I was told it would be better than time.Sleep, but I don’t see any significant difference in the "leak" when I use one or the other. 



-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b8103128-8ae8-42fb-8b3f-4d5265632246%40googlegroups.com.




-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/510361487.825.1583510954972%40wamui-molly.atl.sa.earthlink.net.

[go-nuts] Re: Memory leak or GC feature ?

[Christophe Meessen]

The documentation of the GC() function states:

"GC runs a garbage collection and blocks the caller until the garbage 
collection is complete. It may also block the entire program."

Based on the documentation, I assumed that a garbage collection would be 
really complete by calling GC. By complete I mean that no garbage is left 
over.

Apparently It’s not the case. Is it possible learn a bit more on this ? Why 
would the GC not garbage collect everything when GC() is called ? 

It would have been convenient for detecting memory leaks to be able to 
compare memory Alloc before and after the checked task and a really 
complete GC. 




Le vendredi 6 mars 2020 15:26:33 UTC+1, Volker Dobler a écrit :
>
> This is normal behaviour and not a leak.
> Nothing is leaking in your code (and it is generally
> hard to leak RAM). The allocations will be reclaimed.
>
> V.
>
> On Friday, 6 March 2020 14:11:37 UTC+1, Christophe Meessen wrote:
>>
>> I wanted to check my program for go routine and memory leaks. In doing so 
>> I detected what resemble a memory leak while my program was doing nothing. 
>>
>> Here is a minimal program that reproduces the problem. The program 
>> collects and prints the total number of bytes allocated and the number of 
>> blocks. 
>>
>> package main
>>
>> import (
>> "runtime"
>>
>> func main() {
>> var m runtime.MemStats
>> ticker := time.NewTicker(20 * time.Second)
>> for {
>> runtime.ReadMemStats(&m)
>> println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees, 
>> "numGC", m.NumGC)
>> <-ticker.C
>> runtime.GC()
>> }
>> }
>>
>> What I see is a slow but steady increase of memUse and allocs. The memUse 
>> grows by 4 to 96 bytes every 40 to 60 seconds. 
>> Is this a feature of the GC or is this a memory leak in one of the called 
>> functions ? 
>>
>> Note that I use println because the "leak" is much more important when I 
>> use fmt.Println of log.Println. I also use ticker because I was told it 
>> would be better than time.Sleep, but I don’t see any significant difference 
>> in the "leak" when I use one or the other. 
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b8103128-8ae8-42fb-8b3f-4d5265632246%40googlegroups.com.

Re: [go-nuts] Pass C struct from Go to C method

[Nitish Saboo]

Thankyou Ian for your responses.

Thanks,
Nitish


On Fri, 6 Mar 2020, 21:01 Ian Lance Taylor,  wrote:

> On Fri, Mar 6, 2020 at 7:18 AM Nitish Saboo 
> wrote:
> >
> > > 3) Why is 'fmt.Println(InitStruct)' printing the struct fields even
> after freeing the memory ? [b]
> >
> > Because that's how C works.  C is not a memory safe language, and it
> > doesn't become memory safe just because you make the calls from Go.
> >
> > 1)You mean to say the dangling pointer will return the struct fields
> unless we make it 'nil' explicitly ..am i correct ?
>
> What you get by dereferencing a dangling pointer is unpredictable.  If
> you dereference it immediately after the C.free, as you are doing, you
> will typically get the same values as before the C.free.  Even that
> can vary depending on the behavior of the C memory allocator.
>
> If you set the pointer to nil, then you no longer have a dangling pointer.
>
> https://en.wikipedia.org/wiki/Dangling_pointer
>
> > 2) Here, C.free() will completely free the memory allocation ...right ?
>
> Yes, it will completely free the memory allocated by C.calloc.
>
> Ian
>
>
> > On Fri, Mar 6, 2020 at 7:55 PM Ian Lance Taylor  wrote:
> >>
> >> On Fri, Mar 6, 2020 at 4:25 AM Nitish Saboo 
> wrote:
> >> >
> >> > So what did I do :
> >> >
> >> > main.go
> >> > 
> >> >
> >> > var InitStruct *C.struct_Foo;
> >> >
> >> > func InitializeEngine(pattern string, path string) {
> >> > pattern_db := C.CString(pattern)
> >> > module_path := C.CString(path)
> >> > if InitStruct != nil{
> >> > C.free(unsafe.Pointer(InitStruct))
> >> > }
> >> > InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> >> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> >> > InitStruct.data = C.int(5)
> >> > fmt.Println(InitStruct)  '&{0x4b7cb0 5 [0 0 0
> 0]}' got printed
> >> > fmt.Printf("%p\n", InitStruct)
> <'0x1905630' got printed
> >> > C.initialize_engine(pattern_db, module_path, InitStruct)
> >> >
> >> > }
> >> >
> >> > func ReloadPatternDB(patterndb string) {
> >> >
> >> > if InitStruct != nil{
> >> > fmt.Println(InitStruct) <<<'&{0x4b7cb0 5 [0 0 0 0]}' got
> printed
> >> > fmt.Printf("%p\n", InitStruct) <'0x1905630' got printed
> >> > C.free(unsafe.Pointer(InitStruct))
> >> > fmt.Printf("%p\n", InitStruct). <<<'0x1905630' got printed
> ...Older memory address getting printed even after freeing the memory [a]
> >> > fmt.Println(InitStruct). <<'&{0x863b470 5 [0 0 0 0]}' got
> printed. Why is struct fields getting printed? [b]
> >> > }
> >> > path := C.CString(patterndb)
> >> > InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> >> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> >> > InitStruct.data = C.int(5)
> >> > fmt.Println(InitStruct)<<<
> '&{0x4b7cb0 5 [0 0 0 0]}' got printed
> >> > C.reload_pattern_db(path, InitStruct) <. '0x9031d40' got
> printed
> >> >
> >> > }
> >> >
> >> >
> >> > InitStruct is a global variable.I am calling C functions
> 'initialize_engine' and 'reload_pattern_db' respectively.
> >> >
> >> > 1) Even after freeing the memory in 'reload_pattern_db', the older
> memory address is getting printed.Why? [a]
> >>
> >> Here you are using calls to C.calloc and C.free, so you are using C
> >> pointers and C memory allocation.  That is fine.  But in C, calling
> >> C.free doesn't somehow zero out the pointer.  It leaves the pointer
> >> unchanged, and it becomes a dangling pointer that is unsafe to use.
> >> Basically, if you use C calls, you get C behavior.  That is true even
> >> when calling the C functions from Go.
> >>
> >> > 2) Do I have to explicitly point 'InitStruct=nil' after freeing the
> memory.
> >>
> >> Yes, that will remove the dangling pointer.
> >>
> >> > 3) Why is 'fmt.Println(InitStruct)' printing the struct fields even
> after freeing the memory ? [b]
> >>
> >> Because that's how C works.  C is not a memory safe language, and it
> >> doesn't become memory safe just because you make the calls from Go.
> >>
> >> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALjMrq7WUzRhU%3Dj2O-SxpYGNhPBm2-8oSfVcOtmVUDP8%2BEw3BQ%40mail.gmail.com.

Re: [go-nuts] Pass C struct from Go to C method

[Ian Lance Taylor]

On Fri, Mar 6, 2020 at 7:18 AM Nitish Saboo  wrote:
>
> > 3) Why is 'fmt.Println(InitStruct)' printing the struct fields even after 
> > freeing the memory ? [b]
>
> Because that's how C works.  C is not a memory safe language, and it
> doesn't become memory safe just because you make the calls from Go.
>
> 1)You mean to say the dangling pointer will return the struct fields unless 
> we make it 'nil' explicitly ..am i correct ?

What you get by dereferencing a dangling pointer is unpredictable.  If
you dereference it immediately after the C.free, as you are doing, you
will typically get the same values as before the C.free.  Even that
can vary depending on the behavior of the C memory allocator.

If you set the pointer to nil, then you no longer have a dangling pointer.

https://en.wikipedia.org/wiki/Dangling_pointer

> 2) Here, C.free() will completely free the memory allocation ...right ?

Yes, it will completely free the memory allocated by C.calloc.

Ian


> On Fri, Mar 6, 2020 at 7:55 PM Ian Lance Taylor  wrote:
>>
>> On Fri, Mar 6, 2020 at 4:25 AM Nitish Saboo  wrote:
>> >
>> > So what did I do :
>> >
>> > main.go
>> > 
>> >
>> > var InitStruct *C.struct_Foo;
>> >
>> > func InitializeEngine(pattern string, path string) {
>> > pattern_db := C.CString(pattern)
>> > module_path := C.CString(path)
>> > if InitStruct != nil{
>> > C.free(unsafe.Pointer(InitStruct))
>> > }
>> > InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
>> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
>> > InitStruct.data = C.int(5)
>> > fmt.Println(InitStruct)  '&{0x4b7cb0 5 [0 0 0 0]}' got 
>> > printed
>> > fmt.Printf("%p\n", InitStruct) 
>> > <'0x1905630' got printed
>> > C.initialize_engine(pattern_db, module_path, InitStruct)
>> >
>> > }
>> >
>> > func ReloadPatternDB(patterndb string) {
>> >
>> > if InitStruct != nil{
>> > fmt.Println(InitStruct) <<<'&{0x4b7cb0 5 [0 0 0 0]}' got 
>> > printed
>> > fmt.Printf("%p\n", InitStruct) <'0x1905630' got printed
>> > C.free(unsafe.Pointer(InitStruct))
>> > fmt.Printf("%p\n", InitStruct). <<<'0x1905630' got printed 
>> > ...Older memory address getting printed even after freeing the memory [a]
>> > fmt.Println(InitStruct). <<'&{0x863b470 5 [0 0 0 0]}' got 
>> > printed. Why is struct fields getting printed? [b]
>> > }
>> > path := C.CString(patterndb)
>> > InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
>> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
>> > InitStruct.data = C.int(5)
>> > fmt.Println(InitStruct)<<< 
>> > '&{0x4b7cb0 5 [0 0 0 0]}' got printed
>> > C.reload_pattern_db(path, InitStruct) <. '0x9031d40' got printed
>> >
>> > }
>> >
>> >
>> > InitStruct is a global variable.I am calling C functions 
>> > 'initialize_engine' and 'reload_pattern_db' respectively.
>> >
>> > 1) Even after freeing the memory in 'reload_pattern_db', the older memory 
>> > address is getting printed.Why? [a]
>>
>> Here you are using calls to C.calloc and C.free, so you are using C
>> pointers and C memory allocation.  That is fine.  But in C, calling
>> C.free doesn't somehow zero out the pointer.  It leaves the pointer
>> unchanged, and it becomes a dangling pointer that is unsafe to use.
>> Basically, if you use C calls, you get C behavior.  That is true even
>> when calling the C functions from Go.
>>
>> > 2) Do I have to explicitly point 'InitStruct=nil' after freeing the memory.
>>
>> Yes, that will remove the dangling pointer.
>>
>> > 3) Why is 'fmt.Println(InitStruct)' printing the struct fields even after 
>> > freeing the memory ? [b]
>>
>> Because that's how C works.  C is not a memory safe language, and it
>> doesn't become memory safe just because you make the calls from Go.
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUk0RRCN9YRbnR_iiA9QMHgpY-3X19nZJ9smN3sYEYwnw%40mail.gmail.com.

Re: [go-nuts] Pass C struct from Go to C method

[Nitish Saboo]

Hi Ian,

> 3) Why is 'fmt.Println(InitStruct)' printing the struct fields even after
freeing the memory ? [b]

Because that's how C works.  C is not a memory safe language, and it
doesn't become memory safe just because you make the calls from Go.

1)You mean to say the dangling pointer will return the struct fields unless
we make it 'nil' explicitly ..am i correct ?

2) Here, C.free() will completely free the memory allocation ...right ?

Thanks,
Nitish

On Fri, Mar 6, 2020 at 7:55 PM Ian Lance Taylor  wrote:

> On Fri, Mar 6, 2020 at 4:25 AM Nitish Saboo 
> wrote:
> >
> > So what did I do :
> >
> > main.go
> > 
> >
> > var InitStruct *C.struct_Foo;
> >
> > func InitializeEngine(pattern string, path string) {
> > pattern_db := C.CString(pattern)
> > module_path := C.CString(path)
> > if InitStruct != nil{
> > C.free(unsafe.Pointer(InitStruct))
> > }
> > InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> > InitStruct.data = C.int(5)
> > fmt.Println(InitStruct)  '&{0x4b7cb0 5 [0 0 0 0]}'
> got printed
> > fmt.Printf("%p\n", InitStruct)
> <'0x1905630' got printed
> > C.initialize_engine(pattern_db, module_path, InitStruct)
> >
> > }
> >
> > func ReloadPatternDB(patterndb string) {
> >
> > if InitStruct != nil{
> > fmt.Println(InitStruct) <<<'&{0x4b7cb0 5 [0 0 0 0]}' got
> printed
> > fmt.Printf("%p\n", InitStruct) <'0x1905630' got printed
> > C.free(unsafe.Pointer(InitStruct))
> > fmt.Printf("%p\n", InitStruct). <<<'0x1905630' got printed
> ...Older memory address getting printed even after freeing the memory [a]
> > fmt.Println(InitStruct). <<'&{0x863b470 5 [0 0 0 0]}' got
> printed. Why is struct fields getting printed? [b]
> > }
> > path := C.CString(patterndb)
> > InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> > InitStruct.data = C.int(5)
> > fmt.Println(InitStruct)<<<
> '&{0x4b7cb0 5 [0 0 0 0]}' got printed
> > C.reload_pattern_db(path, InitStruct) <. '0x9031d40' got printed
> >
> > }
> >
> >
> > InitStruct is a global variable.I am calling C functions
> 'initialize_engine' and 'reload_pattern_db' respectively.
> >
> > 1) Even after freeing the memory in 'reload_pattern_db', the older
> memory address is getting printed.Why? [a]
>
> Here you are using calls to C.calloc and C.free, so you are using C
> pointers and C memory allocation.  That is fine.  But in C, calling
> C.free doesn't somehow zero out the pointer.  It leaves the pointer
> unchanged, and it becomes a dangling pointer that is unsafe to use.
> Basically, if you use C calls, you get C behavior.  That is true even
> when calling the C functions from Go.
>
> > 2) Do I have to explicitly point 'InitStruct=nil' after freeing the
> memory.
>
> Yes, that will remove the dangling pointer.
>
> > 3) Why is 'fmt.Println(InitStruct)' printing the struct fields even
> after freeing the memory ? [b]
>
> Because that's how C works.  C is not a memory safe language, and it
> doesn't become memory safe just because you make the calls from Go.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALjMrq6rVCHpFbg4skPDJrYE5w0HAnm684-xmCwsv4a1CuYHkw%40mail.gmail.com.

[go-nuts] Re: Memory leak or GC feature ?

[Volker Dobler]

This is normal behaviour and not a leak.
Nothing is leaking in your code (and it is generally
hard to leak RAM). The allocations will be reclaimed.

V.

On Friday, 6 March 2020 14:11:37 UTC+1, Christophe Meessen wrote:
>
> I wanted to check my program for go routine and memory leaks. In doing so 
> I detected what resemble a memory leak while my program was doing nothing. 
>
> Here is a minimal program that reproduces the problem. The program 
> collects and prints the total number of bytes allocated and the number of 
> blocks. 
>
> package main
>
> import (
> "runtime"
>
> func main() {
> var m runtime.MemStats
> ticker := time.NewTicker(20 * time.Second)
> for {
> runtime.ReadMemStats(&m)
> println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees, "numGC", 
> m.NumGC)
> <-ticker.C
> runtime.GC()
> }
> }
>
> What I see is a slow but steady increase of memUse and allocs. The memUse 
> grows by 4 to 96 bytes every 40 to 60 seconds. 
> Is this a feature of the GC or is this a memory leak in one of the called 
> functions ? 
>
> Note that I use println because the "leak" is much more important when I 
> use fmt.Println of log.Println. I also use ticker because I was told it 
> would be better than time.Sleep, but I don’t see any significant difference 
> in the "leak" when I use one or the other. 
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/62b069b6-2b4c-4372-9821-02602590dde2%40googlegroups.com.

Re: [go-nuts] Pass C struct from Go to C method

[Ian Lance Taylor]

On Fri, Mar 6, 2020 at 4:25 AM Nitish Saboo  wrote:
>
> So what did I do :
>
> main.go
> 
>
> var InitStruct *C.struct_Foo;
>
> func InitializeEngine(pattern string, path string) {
> pattern_db := C.CString(pattern)
> module_path := C.CString(path)
> if InitStruct != nil{
> C.free(unsafe.Pointer(InitStruct))
> }
> InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> InitStruct.data = C.int(5)
> fmt.Println(InitStruct)  '&{0x4b7cb0 5 [0 0 0 0]}' got 
> printed
> fmt.Printf("%p\n", InitStruct) 
> <'0x1905630' got printed
> C.initialize_engine(pattern_db, module_path, InitStruct)
>
> }
>
> func ReloadPatternDB(patterndb string) {
>
> if InitStruct != nil{
> fmt.Println(InitStruct) <<<'&{0x4b7cb0 5 [0 0 0 0]}' got printed
> fmt.Printf("%p\n", InitStruct) <'0x1905630' got printed
> C.free(unsafe.Pointer(InitStruct))
> fmt.Printf("%p\n", InitStruct). <<<'0x1905630' got printed ...Older 
> memory address getting printed even after freeing the memory [a]
> fmt.Println(InitStruct). <<'&{0x863b470 5 [0 0 0 0]}' got 
> printed. Why is struct fields getting printed? [b]
> }
> path := C.CString(patterndb)
> InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> InitStruct.data = C.int(5)
> fmt.Println(InitStruct)<<< 
> '&{0x4b7cb0 5 [0 0 0 0]}' got printed
> C.reload_pattern_db(path, InitStruct) <. '0x9031d40' got printed
>
> }
>
>
> InitStruct is a global variable.I am calling C functions 'initialize_engine' 
> and 'reload_pattern_db' respectively.
>
> 1) Even after freeing the memory in 'reload_pattern_db', the older memory 
> address is getting printed.Why? [a]

Here you are using calls to C.calloc and C.free, so you are using C
pointers and C memory allocation.  That is fine.  But in C, calling
C.free doesn't somehow zero out the pointer.  It leaves the pointer
unchanged, and it becomes a dangling pointer that is unsafe to use.
Basically, if you use C calls, you get C behavior.  That is true even
when calling the C functions from Go.

> 2) Do I have to explicitly point 'InitStruct=nil' after freeing the memory.

Yes, that will remove the dangling pointer.

> 3) Why is 'fmt.Println(InitStruct)' printing the struct fields even after 
> freeing the memory ? [b]

Because that's how C works.  C is not a memory safe language, and it
doesn't become memory safe just because you make the calls from Go.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU0AhwS_J7%2BQD8Bhh6GxF4MY%3DLzxvkxA_%2BMyg9Cm5AEWA%40mail.gmail.com.

[go-nuts] Memory leak or GC feature ?

[Christophe Meessen]

I wanted to check my program for go routine and memory leaks. In doing so I 
detected what resemble a memory leak while my program was doing nothing. 

Here is a minimal program that reproduces the problem. The program collects 
and prints the total number of bytes allocated and the number of blocks. 

package main

import (
"runtime"

func main() {
var m runtime.MemStats
ticker := time.NewTicker(20 * time.Second)
for {
runtime.ReadMemStats(&m)
println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees, "numGC", 
m.NumGC)
<-ticker.C
runtime.GC()
}
}

What I see is a slow but steady increase of memUse and allocs. The memUse 
grows by 4 to 96 bytes every 40 to 60 seconds. 
Is this a feature of the GC or is this a memory leak in one of the called 
functions ? 

Note that I use println because the "leak" is much more important when I 
use fmt.Println of log.Println. I also use ticker because I was told it 
would be better than time.Sleep, but I don’t see any significant difference 
in the "leak" when I use one or the other. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/58e246f2-692f-4246-8728-e28517ed6db0%40googlegroups.com.

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

Nigel,

Thanks!  I can use that in general to wrap pieces of code so that I can 
collapse them in my editor whenever I want!

I was grasping for some concrete way to show this concept -- amid the 
distraction of doing real work.  

Perhaps I should have referenced MIT's Scratch programming tool???  "Go is 
not as good as Scratch" -- THAT would be popular around here I am sure!

My kids learned using Scratch when they were little.

Warren

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/17972908-d271-4d52-b44c-5790bdd4740b%40googlegroups.com.

Re: [go-nuts] Pass C struct from Go to C method

[Nitish Saboo]

Hi Ian,

So what did I do :

main.go


var InitStruct *C.struct_Foo;

func InitializeEngine(pattern string, path string) {
pattern_db := C.CString(pattern)
module_path := C.CString(path)
if InitStruct != nil{
C.free(unsafe.Pointer(InitStruct))
}
InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
InitStruct.data = C.int(5)
fmt.Println(InitStruct)  '&{0x4b7cb0 5 [0 0 0 0]}' got
printed
fmt.Printf("%p\n", InitStruct)
<'0x1905630' got printed
C.initialize_engine(pattern_db, module_path, InitStruct)

}

func ReloadPatternDB(patterndb string) {

if InitStruct != nil{
fmt.Println(InitStruct) <<<'&{0x4b7cb0 5 [0 0 0 0]}' got printed
fmt.Printf("%p\n", InitStruct) <'0x1905630' got printed
C.free(unsafe.Pointer(InitStruct))
fmt.Printf("%p\n", InitStruct). <<<'0x1905630' got printed ...Older
memory address getting printed even after freeing the memory [*a]*
fmt.Println(InitStruct). <<'&{0x863b470 5 [0 0 0 0]}' got
printed. Why is struct fields getting printed? *[b]*
}
path := C.CString(patterndb)
InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
InitStruct.data = C.int(5)
fmt.Println(InitStruct)<<<
'&{0x4b7cb0 5 [0 0 0 0]}' got printed
C.reload_pattern_db(path, InitStruct) <. '0x9031d40' got printed

}


InitStruct is a global variable.I am calling C functions
'initialize_engine' and 'reload_pattern_db' respectively.

1) Even after freeing the memory in 'reload_pattern_db', the older memory
address is getting printed.Why? *[a]*

2) Do I have to explicitly point 'InitStruct=nil' after freeing the memory.

3) Why is 'fmt.Println(InitStruct)' printing the struct fields even after
freeing the memory ? *[b]*

Please clarify what am I missing here ?

Thanks,
Nitish



On Fri, Mar 6, 2020 at 12:19 AM Ian Lance Taylor  wrote:

> On Wed, Mar 4, 2020 at 10:06 PM Nitish Saboo 
> wrote:
> >
> > Thank you for the response.Got it.
> > Basically, fmt.Println(InitStruct) is printing the values of fields, cb
> and data, for the struct Foo pointed by InitStruct.
> > fmt.Printf("%p\n", InitStruct) is printing the memory address.
> > Btw..can you please clarify the following :
> >
> > 1)Is this the correct way to pass a C struct from a Go code to C code.
>
> Sure, this is fine.  There are other ways also, but this approach is fine.
>
> > 2) Can I free the struct memory assigned to Initstruct using calloc on
> Go side  in the following manner ?
> >
> > if InitStruct != nil{
> > C.free(unsafe.Pointer(InitStruct))
> > }
>
> Yes.
>
> Ian
>
> > On Wed, Mar 4, 2020 at 11:19 PM Ian Lance Taylor 
> wrote:
> >>
> >> On Wed, Mar 4, 2020 at 3:57 AM Nitish Saboo 
> wrote:
> >> >
> >> > I have CGO project.
> >> >
> >> > Following is my C header file and Go code
> >> >
> >> > syslog-node.h
> >> > ===
> >> >
> >> > #ifndef _TEST_H_
> >> > #define _TEST_H_
> >> >
> >> > #include 
> >> >
> >> > typedef void (*key_value_cb)(const char* key, const char* value,
> size_t value_len, int work);
> >> > typedef struct Foo{
> >> > key_value_cb cb;
> >> > int data;
> >> > }Foo;
> >> > int initialize_engine(const char* filename, const char* module_path,
> Foo *cb);
> >> > int reload_pattern_db(const char* filename, Foo *cb);
> >> >
> >> >
> >> > cfunc.go
> >> > 
> >> > /*
> >> >
> >> > #include 
> >> >
> >> > // The gateway function
> >> > void callOnMeGo_cgo(char *key, char *value, size_t value_len, int
> work)
> >> > {
> >> > void ParsedData(const char *key, const char *value, size_t value_len,
> int work);
> >> > ParsedData(key, value, value_len, work);
> >> > }
> >> > */
> >> > import "C"
> >> >
> >> > main.go
> >> > 
> >> >
> >> > var InitStruct *C.struct_Foo;
> >> >
> >> > func InitializeEngine(pattern string, path string) {
> >> > pattern_db := C.CString(pattern)
> >> > module_path := C.CString(path)
> >> > if InitStruct != nil{
> >> > C.free(unsafe.Pointer(InitStruct))
> >> > }
> >> > InitStruct := (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
> >> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> >> > InitStruct.data = C.int(0)
> >> > fmt.Println(InitStruct)  <<<'&{0x4b79d0 0 [0
> 0 0 0]}' got printed
> >> > C.initialize_engine(pattern_db, module_path, InitStruct)
> >> >
> >> > }
> >> >
> >> > func ReloadPatternDB(patterndb string) {
> >> >
> >> > path := C.CString(patterndb)
> >> > InitStruct = (*C.Foo)(C.calloc(1, C.sizeof_struct_Foo))
>  << >> > InitStruct.cb = (C.key_value_cb)(C.callOnMeGo_cgo)
> >> > InitStruct.data = C.int(0)
> >> > fmt.Println(InitStruct)<<< '&{0x4b79d0 0
> [0 0 0 0]}' got printed
> >> > C.reload_pattern_db(path, InitStruct)
> >> >
> >> > }
> >> >
> >> >
> >> > I have a Go code where I have to call C functions 'initialize_engine'
> and 'reload_pattern_db' respectively(one af

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Nigel Tao]

On Thu, Mar 5, 2020 at 10:32 AM Warren Stephens
 wrote:
> There is a bunch of "goto nonsense" added to get the Go compiler to accept 
> the 4 labels

Well then, don't use labels, so you don't need nonsense (or the dummy
parameter).

Cutting them out (https://play.golang.org/p/SUalTGaAxmx) runs just
fine, and pretty much lets you do what you want (even if most other Go
programmers, myself included, would write it differently), right? For
example:

> You can put this code into a modern editor with block expansion and 
> contraction, and contract the 3 main steps to easily show (without scrolling) 
> steps 1 to 3.

https://play.golang.org/p/SUalTGaAxmx has blocks, and presumably your
editor can contract them.


> You can then expand step2 alone and see how step2A is clearly a sub-step of 
> step2.

Well, step2A is clearly a sub-step of step2 because of indentation and
being within step2's {} curly braces. I don't think the "step2A"
label/comment really adds much.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOeFMNV04p_C3wA7XtXAQ4wX5QsK4XGXrV1UNk1uHBEemz2wkA%40mail.gmail.com.

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

A few decades ago the Apple Macintosh was not very good either.

Warren

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ea7a95c6-fad5-4d2c-b7c3-eaf65167c302%40googlegroups.com.

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Dan Kortschak]

I wrote cybernetic systems for laboratories with LabView a few decades
ago. Nothing is worth keeping from that system.

On Fri, 2020-03-06 at 00:59 -0800, Warren Stephens wrote:
> How many good tools exist now that will turn linear code into a nice
> looking readable flow chart?  Few? None really?  Take a look at the
> LabView interface.  Google "LabView" and click on "images" -- those
> visual things are programmable.  Clicking on something will take you
> inside it, where the things inside are programmable as well, and so
> on.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cc595fb21682c444985cafe314711f5d09c7b974.camel%40kortschak.io.

Re: [go-nuts] Re: Language proposal: labelled "with" statements to help make test code easier to write

[Warren Stephens]

>
> establish[ed] refactoring tools that are well understood and 
> tested
>

New modes of working need new tools to be developed.  Prior paradigm tools 
are for the prior paradigm.

How many good tools exist now that will turn linear code into a nice 
looking readable flow chart?  Few? None really?  Take a look at the LabView 
interface.  Google "LabView" and click on "images" -- those visual things 
are programmable.  Clicking on something will take you inside it, where the 
things inside are programmable as well, and so on.


The comments in the code above were in the original code from the book.  

But that reminds me -- *another idea* that I have is to merely add special 
comments to code.  These comments would have a formal structure that would 
tell how to arrange the associated block of code in a graphical fashion.  
Something that would be a bit like UML, but less heavy handed.  Something 
that could be "thinly" added a bit at a time to existing code that would 
allow a flow-chart to be "extracted" directly from the source.  These 
special comments would also work across languages -- almost every source 
file in a project allows comments (get on it JSON!).

Imagine getting a new employee and telling her/him to "go add markup to the 
such-and-such project source code until the grapher tool can extract a nice 
high-level diagram".  The employee would learn the code while producing the 
nice diagram -- allowing others to quickly "see" the structure of the 
project.  Add 3 of these special comments, and you would get a 3 block 
diagram.  And 300 of these special comments, and you would get a large 
complicated thing tying almost everything together.  A "linter" would come 
along and tell you which comments don't really match its containing block 
quite correctly.

That approach would not be as advanced as a real visually oriented 
programming language, but would be rather useful, and a step in the right 
direction.

Best,

Warren

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8b0b69e3-8443-47fd-b6c8-180ec818eb22%40googlegroups.com.