[go-nuts] opencv with my golang project

[Ali Hassan]

Opencv install [github.com/shrkwd/opencv-js]
Os : Linux 18.04

 // opencv 
file
   // 
video features
// 
utils file to start

When I compile my project , everything fine but opencv can't start.

-- 
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/17b25a32-4b47-4f8d-a2a5-6657eb8d87a8%40googlegroups.com.

[go-nuts] Re: opencv with my golang project

[Brian Candler]

github.com/shrkwd/opencv-js

That link gives a 404.  Is it a private repository?

-- 
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/e2562df6-9ec2-4c82-99c4-3fd7d27da811%40googlegroups.com.

[go-nuts] Re: How to dump cfg for method ?

[eric fang]

Does anyone know this? Or this is an unimplemented feature ?

在 2020年5月19日星期二 UTC+8下午7:49:53，eric fang写道：
>
> How to generate the cfg of the following Replace method ? I used this 
> command "GOSSAFUNC=Replace:* go tool compile main.go" but it doesn't work. 
> Thanks.
>
> package main
>
> type byteReplacer [256]byte
>
> func (r *byteReplacer) Replace(s string) string {
> var buf []byte // lazily allocated
> for i := 0; i < len(s); i++ {
> b := s[i]
> if r[b] != b {
> if buf == nil {
> buf = []byte(s)
> }
> buf[i] = r[b]
> }
> }
> if buf == nil {
> return s
> }
> return string(buf)
> }
>
> func main() {
> }
>
>

-- 
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/0213048f-b1f8-468b-887d-769df058037e%40googlegroups.com.

[go-nuts] Re: opencv with my golang project

[Ali Hassan]

This is not 
https://github.com/shkrwnd/openCV-js

On Thursday, May 21, 2020 at 1:27:27 PM UTC+5, Ali Hassan wrote:
>
> Opencv install [github.com/shrkwd/opencv-js]
> Os : Linux 18.04
>
>  // opencv 
> file
>// 
> video features
> // 
> utils file to start
>
> When I compile my project , everything fine but opencv can't start.
>
>

-- 
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/88564e7c-3954-44b7-8f6f-3a4e457cd131%40googlegroups.com.

[go-nuts] Re: opencv with my golang project

[Ali Hassan]

sorry i type wrong git link


On Thursday, May 21, 2020 at 1:27:27 PM UTC+5, Ali Hassan wrote:
>
> Opencv install [github.com/shrkwd/opencv-js]
> Os : Linux 18.04
>
>  // opencv 
> file
>// 
> video features
> // 
> utils file to start
>
> When I compile my project , everything fine but opencv can't start.
>
>

-- 
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/d2107bab-0e80-43ae-85b7-c5e506b1f6c2%40googlegroups.com.

[go-nuts] OPENCV + gO

[Ali Hassan]

 *Loading module /opencv.js was blocked because of disallow MIME TYPE 
(TEXT/PLAIN) *ERROR:
>
> First  
>this is valid because my server handle these line 
> Then I add opencv file in /js folder . Next import cv from "/js/opencv.js";

but i have an error

javascript  , then html 
file 
 
 






-- 
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/23dbf03e-24fc-4743-9bba-94a2e5d507ac%40googlegroups.com.

Re: [go-nuts] Re: http包的Respose,不全部读取就不能关闭吗?

[dioptre]

You ever get an answer to this? 

On Friday, March 15, 2013 at 9:24:30 PM UTC-7, Tong Sun wrote:
>
> Not to question the decision, but that seem really counter-intuitive, as I 
> think people stop web requests in the middle all the times. 
>
> Why go insists on reading the _entire_ response body 
> before resp.Body.Close(), even some 700mb has to be read and discarded? 
> Again, just curious to know. Also, any other method that allow people 
>  stop in the middle of web requests? 
>
> Thanks
>
> On Friday, March 15, 2013 9:10:32 PM UTC-4, Dave Cheney wrote:
>>
>> That is correct. You _must_ close the response body, and closing the 
>> response body _must_ read all the data on the connection so it can 
>> return the connection to the connection pool. 
>>
>> On Sat, Mar 16, 2013 at 12:06 PM, Wendal Chen  
>> wrote: 
>> > So, I can't close it before read ALL data? 
>> > 
>> > 
>> > 2013/3/16 Dave Cheney  
>> >> 
>> >> Calling resp.Body.Close() must read the _entire_ response body (some 
>> >> 700mb). 
>>
>

-- 
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/bd6e7c51-f209-46ef-9d17-5e58a5d383d2%40googlegroups.com.

Re: [go-nuts] Re: http包的Respose,不全部读取就不能关闭吗?

[Robert Engels]

You can stop on the middle of the request - but then you cannot reuse the http 
connection. 

If you want more advanced reuse you need to transfer in chunks and have a 
higher level protocol

Also, I think this is addressed in HTTP2 since all connections are multiplexed 
anyway. 

> On May 21, 2020, at 1:37 PM, diop...@gmail.com wrote:
> 
> 
> You ever get an answer to this? 
> 
>> On Friday, March 15, 2013 at 9:24:30 PM UTC-7, Tong Sun wrote:
>> Not to question the decision, but that seem really counter-intuitive, as I 
>> think people stop web requests in the middle all the times. 
>> 
>> Why go insists on reading the _entire_ response body before 
>> resp.Body.Close(), even some 700mb has to be read and discarded? Again, just 
>> curious to know. Also, any other method that allow people  stop in the 
>> middle of web requests? 
>> 
>> Thanks
>> 
>>> On Friday, March 15, 2013 9:10:32 PM UTC-4, Dave Cheney wrote:
>>> That is correct. You _must_ close the response body, and closing the 
>>> response body _must_ read all the data on the connection so it can 
>>> return the connection to the connection pool. 
>>> 
>>> On Sat, Mar 16, 2013 at 12:06 PM, Wendal Chen  wrote: 
>>> > So, I can't close it before read ALL data? 
>>> > 
>>> > 
>>> > 2013/3/16 Dave Cheney  
>>> >> 
>>> >> Calling resp.Body.Close() must read the _entire_ response body (some 
>>> >> 700mb). 
> 
> -- 
> 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/bd6e7c51-f209-46ef-9d17-5e58a5d383d2%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/88A8757C-5234-4C12-B1FB-97042A79F1FD%40ix.netcom.com.

Re: [go-nuts] Is there a possible to add sync.Pool to io.copyBuffer

[qingyunha]

Thank you!  I change the code as your suggestion, it reduce 10% cpu usage.

在 2020年5月21日星期四 UTC+8下午1:04:34，Ian Lance Taylor写道：
>
> On Wed, May 20, 2020 at 9:26 PM > wrote: 
> > 
> > Hi all: 
> > I write a simpile HTTP proxy，and find the most alloctions appear in 
> io.copyBuffer 
> > 
> >>> (pprof) list io.copyBuffer 
> >>> 
> >>> Total: 2.80TB 
> >>> 
> >>> ROUTINE  io.copyBuffer in 
> /usr/local/go/src/io/io.go 
> >>> 
> >>> 1.03TB 2.47TB (flat, cum) 88.16% of Total 
> >>> 
> >>>  .  .383:   if wt, ok := src.(WriterTo); ok { 
> >>> 
> >>>  .  .384:   return wt.WriteTo(dst) 
> >>> 
> >>>  .  .385:   } 
> >>> 
> >>>  .  .386:   // Similarly, if the writer has a 
> ReadFrom method, use it to do the copy. 
> >>> 
> >>>  .  .387:   if rt, ok := dst.(ReaderFrom); ok { 
> >>> 
> >>>  . 3.02GB388:   return rt.ReadFrom(src) 
> >>> 
> >>>  .  .389:   } 
> >>> 
> >>>  .  .390:   if buf == nil { 
> >>> 
> >>>  .  .391:   size := 32 * 1024 
> >>> 
> >>>  .  .392:   if l, ok := 
> src.(*LimitedReader); ok && int64(size) > l.N { 
> >>> 
> >>>  .  .393:   if l.N < 1 { 
> >>> 
> >>>  .  .394:   size = 1 
> >>> 
> >>>  .  .395:   } else { 
> >>> 
> >>>  .  .396:   size = 
> int(l.N) 
> >>> 
> >>>  .  .397:   } 
> >>> 
> >>>  .  .398:   } 
> >>> 
> >>> 1.03TB 1.03TB399:   buf = make([]byte, size) 
> >>> 
> >>>  .  .400:   } 
> >>> 
> >>>  .  .401:   for { 
> >>> 
> >>>  . 1.43TB402:   nr, er := src.Read(buf) 
> >>> 
> >>>  .  .403:   if nr > 0 { 
> >>> 
> >>>  .   569.57MB404:   nw, ew := 
> dst.Write(buf[0:nr]) 
> >>> 
> >>>  .  .405:   if nw > 0 { 
> >>> 
> >>>  .  .406:   written += 
> int64(nw) 
> >>> 
> >>>  .  .407:   } 
> >>> 
> >>>  .  .408:   if ew != nil { 
> >>> 
> >>>  .  .409:   err = ew 
> > 
> > 
> > and this the stacktrace 
> >> 
> >> 0: 0 [2057907: 67433496576] @ 0x470169 0x6e508a 0x6e5042 0x6e4ca7 
> 0x6cf82e 0x77bfe9 0x45f7a1 
> >> 
> >> #   0x470168io.copyBuffer+0x2a8 
> /usr/local/go/src/io/io.go:399 
> >> 
> >> #   0x6e5089io.Copy+0x69   
>  /usr/local/go/src/io/io.go:364 
> >> 
> >> #   0x6e5041net/http.(*transferWriter).doBodyCopy+0x21 
>  /usr/local/go/src/net/http/transfer.go:400 
> >> 
> >> #   0x6e4ca6net/http.(*transferWriter).writeBody+0x426 
>  /usr/local/go/src/net/http/transfer.go:348 
> >> 
> >> #   0x6cf82dnet/http.(*Response).Write+0x42d   
>  /usr/local/go/src/net/http/response.go:328 
> >> 
> >> #   0x77bfe8main.handler+0x318 
>  /root/ctrip/shendun/main.go:74 
>
>
> The data being copied is presumably coming from the Body field of your 
> *http.Response.  If you set the Body field to a type that implements 
> the WriteTo method, and set the ContentLength field to the length of 
> the data, then you can do the write however you like. 
>
> 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/74064ed5-6650-4acc-9256-23e020182274%40googlegroups.com.

[go-nuts] Weird problem that CPU is nearly 100%

[tokers]

Hi!

We have a go program (an api server) on a virtual machine(with 8 cores) 
with a long time stable running.
However, the program recently suffered a weird problem that only a single 
CPU reached 100%
usage while others were very low, in the meanwhile, the network bandwidth 
was totally zero,
also, there were a bunch of tcp connections with CLOSE_WAIT state on the 
server side.
So it seems to me that the program was busily spinning on some events and 
cannot execute our codes.

We sent a QUIT signal to it and got its goroutine stacks, there were 3000+ 
goroutines on there, only two goroutines
were running but 370 goroutines were runnable, others were blocked on the 
channel events. Unfortunately, these two gouroutine stacks
were not available since the "goroutine running on other thread".

We didn't adjust runtime.GOMAXPROCS so the default Ps in Go should be the 
number of processors, i.e. 8. In my
view, the number of running goroutines should be larger, and it seems the 
runq size was somewhat large (even we have
8 Ms which are running user goroutines, the average runq size is 46, if we 
only the global runq).

I don't know what did other Ms do at that time, I know there is a mark 
assistant mechanism in the garbage collector implementation.
But will it use a log of Ms and make the scheduler in trouble?

Go version we use: go/1.12.13.
Os we use: CentOS/3.10.0.

-- 
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/87d85095-a8f1-49e9-b079-1e9fe2089a31%40googlegroups.com.

Re: [go-nuts] Weird problem that CPU is nearly 100%

[Ian Lance Taylor]

On Thu, May 21, 2020 at 8:55 PM tokers  wrote:
>
> We have a go program (an api server) on a virtual machine(with 8 cores) with 
> a long time stable running.
> However, the program recently suffered a weird problem that only a single CPU 
> reached 100%
> usage while others were very low, in the meanwhile, the network bandwidth was 
> totally zero,
> also, there were a bunch of tcp connections with CLOSE_WAIT state on the 
> server side.
> So it seems to me that the program was busily spinning on some events and 
> cannot execute our codes.
>
> We sent a QUIT signal to it and got its goroutine stacks, there were 3000+ 
> goroutines on there, only two goroutines
> were running but 370 goroutines were runnable, others were blocked on the 
> channel events. Unfortunately, these two gouroutine stacks
> were not available since the "goroutine running on other thread".
>
> We didn't adjust runtime.GOMAXPROCS so the default Ps in Go should be the 
> number of processors, i.e. 8. In my
> view, the number of running goroutines should be larger, and it seems the 
> runq size was somewhat large (even we have
> 8 Ms which are running user goroutines, the average runq size is 46, if we 
> only the global runq).
>
> I don't know what did other Ms do at that time, I know there is a mark 
> assistant mechanism in the garbage collector implementation.
> But will it use a log of Ms and make the scheduler in trouble?
>
> Go version we use: go/1.12.13.
> Os we use: CentOS/3.10.0.

Without seeing the code it's impossible to know, but the most likely
cause is that the goroutines were running in an unpreemptible loop,
that the rest of the goroutines were stuck waiting for a garbage
collection phase change, and that the garbage collector was waiting
for those two goroutines to complete.

Fortunately this kind of problem was fixed in 1.14, so I recommend upgrading.

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/CAOyqgcUpOLjswaqHWD4rt8WfvF_yGoVKEtYPo5MA299rSvJ_hA%40mail.gmail.com.

[go-nuts] Re: opencv with my golang project

[Brian Candler]

OK, so far you've shown some HTML and some Javascript.

However, you said you had a problem with a go project.  Can you write a 
small standalone go program which reproduces the problem?

-- 
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/550dbb95-a3e5-482e-89df-636cd9802968%40googlegroups.com.