[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

2020-03-12 Thread Agniva De Sarker


On Wednesday, 11 March 2020 18:52:15 UTC+5:30, howar...@gmail.com wrote:
>
> I've no relevant experience, but I can recommend a couple of projects to 
> look at in the absence of anyone chiming in with actual experience:
>
> https://agniva.me/wasm/2018/06/18/shimmer-wasm.html
> https://github.com/agnivade/shimmer
> This is a play-project that involves loading images. It appears to be 
> using a side-load method of converting the image to Base64 and assigning it 
> to the image's src attribute - so it is not using the canvas directly, but 
> if a call to the canvas can draw an image from a URL, this might work - 
> have a look at
>
> // updateImage writes the image to a byte buffer and then converts it to 
> base64.
> // Then it sets the value to the src attribute of the target image.
> func (s *Shimmer) updateImage(img *image.RGBA, start time.Time) 
>

Woops, that comment is outdated and needs to be fixed. The blog post is 
also outdated now :D.
There is no base64 conversion now anywhere. If you read the code below, 
you'll see I use 

dst := js.Global().Get("Uint8Array").New(len(s.outBuf.Bytes()))
n := js.CopyBytesToJS(dst, s.outBuf.Bytes())
s.console.Call("log", "bytes copied:", strconv.Itoa(n))
js.Global().Call("displayImage", dst)

Essentially, I copy over the bytes to the array and pass the array over to 
JS land.

And then displayImage does this:

function displayImage(buf) {
  let blob = new Blob([buf], {'type': imageType});
  document.getElementById('targetImg').src = URL.createObjectURL(blob);
} 

Before the CopyBytesToJS  
API, 
I used unsafe to get the slice header and then pass it to JS, and populate 
the slice with the image contents. Definitely hacky, but that did not 
require passing the entire image from JS to wasm. With the new API, we are 
back to passing data, but it's a lot safer.

Coming to the original problem, yes there is no Uint8ClampedArray support. 
People have already raised it here: 
https://github.com/golang/go/issues/32402. I think you can use a similar 
hack for your purposes.

Feel free to hop in to #webassembly slack channel if you have more 
questions.

-Agniva


> in https://github.com/agnivade/shimmer/blob/master/shimmer.go
>
> Here is another project that also went with the Base64 method of passing 
> the array, look for the section labeled "Pixels are Pixels": 
>
> https://blog.jeremylikness.com/blog/2019-03-03_gopher-meet-plasma-a-webassembly-experiment/
>
> His final verdict was that the pure Javascript version performed better 
> than the Go-WASM+JS version.
>

-- 
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/2eab5b50-9168-4584-ab42-11bac47ea8d4%40googlegroups.com.


Re: [go-nuts] Simple worker pool in golnag

2019-12-28 Thread Agniva De Sarker
Perhaps I wasn't clear, but I am not suggesting to use one goroutine per
table. You can limit the no. of goroutines running (say 25 at a time) by
just spawning them and wait for the entire task to complete, without
creating a worker pool of 25 goroutines. It is basically a counting
semaphore with a buffered channel.

On Sun, Dec 29, 2019 at 12:31 AM Chris Burkert 
wrote:

> I needed a way to let the database complete a few tables (max 25) at a
> time without the need for the database to handle other tables in between. A
> worker pool which reads one table after the other does that perfectly. That
> also means that if all workers wait for the database then my whole program
> waits - which is intented. I didn't test it but I guess that one goroutine
> per table would burden the database to handle all tables at once. I asume
> that a goroutine which triggered the database and waits for it to complete
> is put aside by the runtime letting other goroutines also trigger the
> database. And I think then I will have the same out of memory (on the
> database side, not on the Go side). However I try to test the "one
> goroutine per table" approach ... maybe it improves my code and I learn
> something new.
>
> Anyway, all I wanted to say was that there are situations where one
> approach fits more while it may be opposite in another situation. And I
> don't like the term "anti-pattern" as it lets you put ideas aside which may
> be worth thinking about.
>
> Am Sa., 28. Dez. 2019 um 14:01 Uhr schrieb Agniva De Sarker <
> agniva.quicksil...@gmail.com>:
>
>> > (the task was to limit the whole thing to about 10% of cores)
>>
>> I still don't think you needed a worker pool here. Like OP mentioned
>> above, you could just limit the number of goroutines executed to 10% of
>> total cores.
>>
>>
>> On Saturday, 28 December 2019 18:02:08 UTC+5:30, Chris Burkert wrote:
>>>
>>> There are Pros and Cons for everything in life. Some time ago I wrote a
>>> database tool which does something per table where the runtime largely
>>> depends on the table size. I started with one goroutine per table because
>>> it was easy. But that put a high load on the database (the task was to
>>> limit the whole thing to about 10% of cores) with out of memory situations.
>>> So I switched to a worker pool which solved that. However now the overall
>>> runtime was unpredictable. When the large tables were handled at the end
>>> their runtime defined the overall runtime. So I to feed the pool with large
>>> tables first. This again lead to out of memory situations so I reordered
>>> the tables such that large tables are mixed with smaller tables.
>>>
>>> Brian Candler  schrieb am Sa. 28. Dez. 2019 um 11:09:
>>>
>>>> On Friday, 27 December 2019 16:30:48 UTC, Bruno Albuquerque wrote:
>>>>>
>>>>> This might be useful too you, in any case:
>>>>>
>>>>> https://git.bug-br.org.br/bga/workerpool
>>>>>
>>>>>
>>>> I think the point from Bryan Mills' video is, "worker pool" is
>>>> something of an anti-pattern in go.  goroutines are so cheap that you might
>>>> as well start a goroutine for each piece of work you have to do, and let it
>>>> terminate when that piece of work is done.
>>>>
>>>> Apart from the startup cost, the other reason for having a "worker
>>>> pool" is to limit the number of concurrent tasks being executed, and there
>>>> are better ways of doing that in go (also shown in the video).
>>>>
>>>> --
>>>> 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 golan...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/f840beee-748f-42b6-809f-4c7505208aee%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/golang-nuts/f840beee-748f-42b6-809f-4c7505208aee%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>> 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/ecddafbc-eb73-45e1-8a5a-f738e88c6821%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/ecddafbc-eb73-45e1-8a5a-f738e88c6821%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAOpCn4iFxrNV1PGKKsZ%2BfAPKiX%3DN_As4BniLajRZT%2BGR5yTKcA%40mail.gmail.com.


Re: [go-nuts] Simple worker pool in golnag

2019-12-28 Thread Agniva De Sarker
> (the task was to limit the whole thing to about 10% of cores)

I still don't think you needed a worker pool here. Like OP mentioned above, 
you could just limit the number of goroutines executed to 10% of total 
cores.


On Saturday, 28 December 2019 18:02:08 UTC+5:30, Chris Burkert wrote:
>
> There are Pros and Cons for everything in life. Some time ago I wrote a 
> database tool which does something per table where the runtime largely 
> depends on the table size. I started with one goroutine per table because 
> it was easy. But that put a high load on the database (the task was to 
> limit the whole thing to about 10% of cores) with out of memory situations. 
> So I switched to a worker pool which solved that. However now the overall 
> runtime was unpredictable. When the large tables were handled at the end 
> their runtime defined the overall runtime. So I to feed the pool with large 
> tables first. This again lead to out of memory situations so I reordered 
> the tables such that large tables are mixed with smaller tables.
>
> Brian Candler > schrieb am Sa. 28. Dez. 
> 2019 um 11:09:
>
>> On Friday, 27 December 2019 16:30:48 UTC, Bruno Albuquerque wrote:
>>>
>>> This might be useful too you, in any case:
>>>
>>> https://git.bug-br.org.br/bga/workerpool
>>>
>>>
>> I think the point from Bryan Mills' video is, "worker pool" is something 
>> of an anti-pattern in go.  goroutines are so cheap that you might as well 
>> start a goroutine for each piece of work you have to do, and let it 
>> terminate when that piece of work is done.
>>
>> Apart from the startup cost, the other reason for having a "worker pool" 
>> is to limit the number of concurrent tasks being executed, and there are 
>> better ways of doing that in go (also shown in the video).
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f840beee-748f-42b6-809f-4c7505208aee%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/ecddafbc-eb73-45e1-8a5a-f738e88c6821%40googlegroups.com.


Re: [go-nuts] Re: Go WebAssembly(wasm) testing fails - fatal error: unexpected signal during runtime execution

2019-11-14 Thread Agniva De Sarker
Please also try with 1.13.x and see if you see the issue there too. Also
please try running manually in FF too.

On Thu, Nov 14, 2019 at 10:08 PM mihai barbulescu  wrote:

> - Are you able to provide the code which causes this crash ?
>  Not really...it's a big code-base... I will try to reproduce a smaller
> testcase and update the post.
> - Which Go version are you using ?
> go tip
> - Are you testing this in the browser or in Node ? Please give details of
> either.
> In the browser (sort of )
>
> https://github.com/golang/go/wiki/WebAssembly#running-tests-in-the-browser
>
> joi, 14 noiembrie 2019, 18:33:48 UTC+2, Agniva De Sarker a scris:
>>
>> Please provide more information so that it helps people to debug the
>> issue. Such as:
>>
>> - Are you able to provide the code which causes this crash ?
>> - Which Go version are you using ?
>> - Are you testing this in the browser or in Node ? Please give details of
>> either.
>>
>>
>>
>> On Thursday, 14 November 2019 18:52:49 UTC+5:30, mihai barbulescu wrote:
>>>
>>> I'm building a client-side webapp and part of this I would like to run
>>> tests. It seems testing fails . Is it a known issue ?
>>>
>>>
>>> Mihai
>>>
>>> server thetv$ GOOS=js GOARCH=wasm go test
>>> --- FAIL: TestServer (3.00s)
>>> fatal error: unexpected signal during runtime execution
>>>
>>> runtime stack:
>>> runtime: unexpected return pc for syscall.fsCall called from
>>> 0x15d70a5c1ade6900
>>> stack: frame={sp:0xb23170, fp:0xb23208} stack=[0xb21698,0xb23298)
>>> 00b23070:  00143b44  002a
>>> 00b23080:  00b00de0  10e20003
>>> 
>>> 00b23090:  0001  000b52bf
>>> 00b230a0:  5bab0011 
>>> 00c3e368
>>> 00b230b0:  00c3e3b8  105e001a
>>> 
>>> 00b230c0:    00b231e8
>>> 00b230d0:  0005  
>>> 00b230e0:  109e0010 
>>> 
>>> 00b230f0:  0003  0005
>>> 00b23100:  008affbb0c00  0001
>>> 00b23110:  15d709d10001  15d70a5c1ade6900
>>> 00b23120:  00c32300  00c30058
>>> 00b23130:    008e6901
>>> 00b23140:  105d0002 
>>> 00c3
>>> 00b23150:  00b231e8  0001
>>> 00b23160:  00b06600  1512000d
>>> 
>>> 00b23170: <00c3  00b231e8
>>> 00b23180:  12250010 
>>> 00010001
>>> 00b23190:  0001  00c3e3b8
>>> 00b231a0:    00c305d8
>>> 00b231b0:  15d709d10005  00c3
>>> 00b231c0:  00050004  00b00de0
>>> 00b231d0:  15d709d11b235d00  00c3
>>> 00b231e0:  1248005e 
>>> 
>>> 00b231f0:    
>>> 00b23200: !15d70a5c1ade6900 >10a0
>>> 
>>> 00b23210:  00ac0820  1354
>>> 
>>> 00b23220:  10a0 
>>> 00b00de0
>>> 00b23230:  00c00c90  0006
>>> 00b23240:  1251002b 
>>> 00c3
>>> 00b23250:  00c00c00  00c00900
>>> 00b23260:  00040002  
>>> 00b23270:  00b00de0  13b40001 
>>> 00b23280:  00c00c00  00b232c0
>>> 00b23290:  0100
>>> syscall.fsCall(0x10a0, 0xac0820, 0x1354, 0x10a0, 0xb00de0,
>>> 0xc00c90, 0x6, 0x1251002b)
>>> /Users/thetv/goroot/src/syscall/fs_js.go:513 +0xd
>>>
>>> goroutine 1 [chan receive]:
>>> testing.(*T).Run(0xca4100, 0x137b68, 0xa, 0x14f008, 0x155b0002)
>>> /Users/thetv/goroot/src/testing/testing.go:977 +0x31
>>> testing.runTests.func1(0xca4000)
>>> /Users/thetv/goroot/src/testing/testing.go:1218 +0x5
>>> testing.tRunner(0xca4000, 0xc56e28)
>>> /Users/thetv/goroot/src/testing/testing.go:925 +0xc
>>> testing.runTests(0xc0a240, 0xaee440, 0x1, 0x1, 0x0)
>>> /Users/thetv/goroot/src/tes

[go-nuts] Re: Go WebAssembly(wasm) testing fails - fatal error: unexpected signal during runtime execution

2019-11-14 Thread Agniva De Sarker
Please provide more information so that it helps people to debug the issue. 
Such as:

- Are you able to provide the code which causes this crash ?
- Which Go version are you using ?
- Are you testing this in the browser or in Node ? Please give details of 
either.



On Thursday, 14 November 2019 18:52:49 UTC+5:30, mihai barbulescu wrote:
>
> I'm building a client-side webapp and part of this I would like to run 
> tests. It seems testing fails . Is it a known issue ?
>
>
> Mihai
>
> server thetv$ GOOS=js GOARCH=wasm go test 
> --- FAIL: TestServer (3.00s)
> fatal error: unexpected signal during runtime execution
>
> runtime stack:
> runtime: unexpected return pc for syscall.fsCall called from 
> 0x15d70a5c1ade6900
> stack: frame={sp:0xb23170, fp:0xb23208} stack=[0xb21698,0xb23298)
> 00b23070:  00143b44  002a 
> 00b23080:  00b00de0  10e20003 
>  
> 00b23090:  0001  000b52bf 
> 00b230a0:  5bab0011   
> 00c3e368 
> 00b230b0:  00c3e3b8  105e001a 
>  
> 00b230c0:    00b231e8 
> 00b230d0:  0005   
> 00b230e0:  109e0010   
>  
> 00b230f0:  0003  0005 
> 00b23100:  008affbb0c00  0001 
> 00b23110:  15d709d10001  15d70a5c1ade6900 
> 00b23120:  00c32300  00c30058 
> 00b23130:    008e6901 
> 00b23140:  105d0002   
> 00c3 
> 00b23150:  00b231e8  0001 
> 00b23160:  00b06600  1512000d  
> 00b23170: <00c3  00b231e8 
> 00b23180:  12250010   
> 00010001 
> 00b23190:  0001  00c3e3b8 
> 00b231a0:    00c305d8 
> 00b231b0:  15d709d10005  00c3 
> 00b231c0:  00050004  00b00de0 
> 00b231d0:  15d709d11b235d00  00c3 
> 00b231e0:  1248005e   
>  
> 00b231f0:     
> 00b23200: !15d70a5c1ade6900 >10a0 
>  
> 00b23210:  00ac0820  1354 
>  
> 00b23220:  10a0   
> 00b00de0 
> 00b23230:  00c00c90  0006 
> 00b23240:  1251002b   00c3 
> 00b23250:  00c00c00  00c00900 
> 00b23260:  00040002   
> 00b23270:  00b00de0  13b40001  
> 00b23280:  00c00c00  00b232c0 
> 00b23290:  0100 
> syscall.fsCall(0x10a0, 0xac0820, 0x1354, 0x10a0, 0xb00de0, 
> 0xc00c90, 0x6, 0x1251002b)
> /Users/thetv/goroot/src/syscall/fs_js.go:513 +0xd
>
> goroutine 1 [chan receive]:
> testing.(*T).Run(0xca4100, 0x137b68, 0xa, 0x14f008, 0x155b0002)
> /Users/thetv/goroot/src/testing/testing.go:977 +0x31
> testing.runTests.func1(0xca4000)
> /Users/thetv/goroot/src/testing/testing.go:1218 +0x5
> testing.tRunner(0xca4000, 0xc56e28)
> /Users/thetv/goroot/src/testing/testing.go:925 +0xc
> testing.runTests(0xc0a240, 0xaee440, 0x1, 0x1, 0x0)
> /Users/thetv/goroot/src/testing/testing.go:1216 +0x28
> testing.(*M).Run(0xca2000, 0x0)
> /Users/thetv/goroot/src/testing/testing.go:1133 +0x1b
> main.main()
> _testmain.go:44 +0xd
>
> goroutine 6 [waiting]:
> syscall/js.Value.Call(0x7ff8000a, 0x13655c, 0x5, 0xc76aa0, 0x6, 
> 0xa, 0x5)
> /Users/thetv/goroot/src/syscall/js/js.go:326 +0x3
> syscall.fsCall(0x13655c, 0x5, 0xc58bf8, 0x5, 0x5, 0x401, 0x1378ac0, 
> 0x3)
> /Users/thetv/goroot/src/syscall/fs_js.go:496 +0xc
> syscall.Write(0x1, 0xc74400, 0x1d, 0x400, 0x1d, 0xb2ee68, 0xcac500)
> /Users/thetv/goroot/src/syscall/fs_js.go:417 +0x11
> internal/poll.(*FD).Write(0xc3e120, 0xc74400, 0x1d, 0x400, 0x0, 0x0, 0x0)
> /Users/thetv/goroot/src/internal/poll/fd_unix.go:268 +0x22
> os.(*File).write(...)
> /Users/thetv/goroot/src/os/file_unix.go:280
> os.(*File).Write(0xc0c020, 0xc74400, 0x1d, 0x400, 0x3, 0x3, 0xc2ce01)
> /Users/thetv/goroot/src/os/file.go:153 +0xf
> fmt.Fprintf(0x1949c0, 0xc0c020, 0x139be8, 0x10, 0xc58e78, 0x3, 0x3, 
> 0xb232c8, 0x0, 0x19340006)
> /Users/thetv/goroot/src/fmt/print.go:205 +0x8
> testing.(*common).flushToParent(0xca4100, 0x139be8, 0x10, 0xc58e78, 0x3, 
> 0x3)
> /Users/thetv/goroot/src/testing/testing.go:508 +0x7
> testing.(*T).report(0xca4100)
> /Users/thetv/goroot/src/testing/testing.go:1155 +0x18
> testing.tRunner.func1(0xca4100)
> /Users/thetv/goroot/src/testing/testing.go:912 +0x41
> testing.tRunner(0xca4100, 0x14f008)
> /Users/thetv/goroot/src/testing/testing.go:929 +0xd
> 

[go-nuts] Re: SSA-able and canSSA meaning in Go compiler's SSA backend?

2019-09-19 Thread Agniva De Sarker
> Here is a link to a talk from a Go developer about adding SSA to the 
compiler

That Go developer is the one who answered OP's question :)

On Thursday, 19 September 2019 17:55:33 UTC+5:30, howar...@gmail.com wrote:
>
> Read this wiki page to understand what the goal is:
> https://en.wikipedia.org/wiki/Static_single_assignment_form
>
> Basically, SSA-form allows certain optimizations that are harder without 
> it, but SSA is also itself hard to apply. SSA examples are often posed in 
> the form of simple variables, but real code has structs and arrays and maps 
> and slices. So they mark things that are worth the effort of applying SSA 
> to and things they've (the compiler writers, that is) have decided are not 
> worth of pushing down to an SSA form.
>
> So, the special purpose it serves is to enable a class of optimizations. 
> And the difference from non-SSA-able values is simply one of cost/benefit. 
> Non-SSA-able values are actually those where implementing SSA was deemed 
> either not possible or too expensive (either in terms of time, or code, or 
> just the compiler author's brainspace).
>
> Here is a link to a talk from a Go developer about adding SSA to the 
> compiler:
> https://about.sourcegraph.com/go/generating-better-machine-code-with-ssa
>
> (P.S. if this ends up posting multiple times, I apologize. It has told me 
> there was an error communicating with the server twice 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2ed33b77-2b01-4395-a163-5f88b91963d3%40googlegroups.com.


[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

2019-08-10 Thread Agniva De Sarker
Can you show me how is it possible to do with pkg/errors ? It is not 
immediately apparent to me. The Causer interface is similar to the Unwrap 
interface and errors.Cause recursively unwraps an error until it finds one 
which does not implements the causer interface. So just with 
errors.WithMessage/Wrap, you can only unwrap an error, but cannot directly 
compare a nested untyped/unnamed error variable.


On Friday, 9 August 2019 23:21:57 UTC+5:30, Alex wrote:
>
> Yes, sure. This is always possible. :-)
>
> But this is kind of writing your own error wrapper. I was just wondering 
> if this is somehow possible with the new error wrapper like it was with 
> https://github.com/pkg/errors.
>
> Am Freitag, 9. August 2019 19:35:42 UTC+2 schrieb Agniva De Sarker:
>>
>> I see. One way is to create a wrapper error type in layer1, which takes a 
>> layer2 error.  Just like os.PathError.
>>
>> package main
>>
>> import (
>> "errors"
>> "fmt"
>> )
>>
>> var (
>> // Layer1Error = errors.New("some error on layer 1")
>> Layer2Error = errors.New("some error on layer 2")
>> )
>>
>> type Layer1Error struct {
>> internal error
>> }
>>
>> func (le *Layer1Error) Error() string {
>> return fmt.Sprintf("layer2 error: %v", le.internal)
>> }
>>
>> func (le *Layer1Error) Unwrap() error {
>> return le.internal
>> }
>>
>> func main() {
>> err := callLayer1Function()
>> fmt.Println(errors.Is(err, Layer2Error))
>> var l2err *Layer1Error
>> fmt.Println(errors.As(err, ))
>> }
>>
>> func callLayer1Function() error {
>> err := callLayer2Function()
>> return {err}
>> }
>>
>> func callLayer2Function() error {
>> // wrap an error of Layer2 here
>> return fmt.Errorf("some specific layer2 error message: %w", Layer2Error)
>> }
>>
>>
>> On Friday, 9 August 2019 22:43:11 UTC+5:30, Alex wrote:
>>>
>>> Hi Agniva,
>>>
>>> the problem is: In the main function is no information that there was an 
>>> Layer2 error (layer2 error is not included in the error anymore).
>>> I don't know how to take the error from layer2 and wrap another error 
>>> (layer1-error) around it.
>>>
>>> You can only use the verb "%w" once in a fmt.Errorf() function afaik.
>>> So if you have a wrapped error object e1, how would you enrich / wrap 
>>> this with another error e2?
>>>
>>>
>>> Thanks,
>>> Alex
>>>
>>

-- 
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/b4b65eec-fcc9-457f-af2c-6ea99cabc49f%40googlegroups.com.


[go-nuts] Re: How to propagate multiple errors using the new fmt.Errorf wrapping

2019-08-09 Thread Agniva De Sarker
This is the right way. What is the issue you are facing ? See 
https://tip.golang.org/pkg/errors/ for more info.

You can check for Layer1Error and Layer2Error using the Is function

errors.Is(err, Layer1Error)

errors.Is(err, Layer2Error)

On Friday, 9 August 2019 19:09:24 UTC+5:30, Alex wrote:
>
> Sorry, mixed things up in the code with layer1 and layer2... 
>
>
> var (
> Layer1Error= errors.New("some error on layer 1")
> Layer2Error= errors.New("some error on layer 2")
> )
>
> func main() {
> err := callLayer1Function()
>
> // do something with error
> }
>
> func callLayer1Function() error {
> err := callLayer2Function()
>
> // how to not lose layer2 error but also append a new layer1 error ?
> // this does not work, since you fully lose layer1 error
> // with pkg/err
> return fmt.Errorf("some specific layer 1 error message: %w", Layer1Error)
> }
>
> func callLayer2Function() error {
> // wrap an error of Layer2 here
> return fmt.Errorf("some specific layer2 error message: %w", Layer2Error)
> }
>
>
>

-- 
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/8a149bf3-fa6b-41b3-94b3-517f41dd373b%40googlegroups.com.


Re: [go-nuts] Go Library lists

2019-08-06 Thread Agniva De Sarker
Also - https://github.com/avelino/awesome-go

On Tuesday, 6 August 2019 19:35:48 UTC+5:30, Jan Mercl wrote:
>
> On Tue, Aug 6, 2019 at 3:51 PM > wrote: 
>
> > If anyone knows of a currently maintained equivalent , please respond 
>
> Check https://github.com/golang/go/wiki/Projects 
>

-- 
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/b8661ffd-4eff-44df-93a8-8ce2c15329ec%40googlegroups.com.


[go-nuts] Re: running godoc in a dir outside gopath

2019-07-28 Thread Agniva De Sarker
Currently, godoc will only show documentation for GOPATH and GOROOT. Work 
is being done to make godoc work with modules.  Feel free to subscribe to 
https://github.com/golang/go/issues/26827.

On Monday, 29 July 2019 04:46:48 UTC+5:30, DrGo wrote:
>
> Hello,
>
> Wondering what I am doing wrong.
>
> Using go13.beta1 (Darwin), I am running a freshly downloaded godoc in a 
> dir that includes several of my own packages like this
>
> godoc -http=localhost:6060 -goroot ~/local/git/
>
> But on the browser, godoc is simply serving a list of all files in the dir 
> (not extracting comments as it is does when I do not specify the -goroot 
> flag). Anyone knows why?
> Perhaps there is another way of making godoc work to show the 
> documentation of my packages other than -goroot?
>
> 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/586a1af6-a470-4970-a592-4b093384ef49%40googlegroups.com.


[go-nuts] Re: Concurrent Routines in WASM

2019-06-23 Thread Agniva De Sarker
The spec is at phase 2. Please feel free to subscribe to 
https://github.com/golang/go/issues/28631 for updates.

On Saturday, 22 June 2019 06:46:56 UTC+5:30, Keith Randall wrote:
>
> No, it doesn't. Do wasm threads exist yet? When the wasm port was first 
> developed, they didn't exist.
> If the spec is now complete, we would just need a builder than can test 
> threads, and then we would implement threading support in tip (for 1.14, 
> presumably). Feel free to submit patches.
>
> It looks like wasm threads is implemented in Chrome 70+, but I'm not sure 
> how that relates to the spec and/or other wasm implementations.
>
> On Friday, June 21, 2019 at 1:13:17 PM UTC-4, samuel@gmail.com wrote:
>>
>> Does the golang WASM compiler support concurrent routines with WASM 
>> threads yet? If not is there a place that I can contribute to its 
>> development?
>>
>

-- 
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/34f44837-f92a-4696-842f-7accbc93c934%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Panic during proto Marshal

2019-06-19 Thread Agniva De Sarker
This happens when you are trying to access a nil pointer. Check from where 
the stack trace originates, go to that line and add a "!= nil" check. I 
guess that is what's happening.

P.S. Your stack trace is in a json format which is for machines to read, 
not humans. While reporting issues, it helps a lot you present your data 
(logs, stack trace, etc) in the most clearest way possible.



On Wednesday, 19 June 2019 11:32:09 UTC+5:30, Mayank Jha wrote:
>
> I am getting the *runtime error: invalid memory address or nil pointer 
> dereference, *with the following stack trace, but only occasionally when 
> I try to proto.Marshal() a proto message. 
>
> [{"file":"/go/src/github.com/carousell/Cats/Cats/analytics/analytics.go",
>> "line":92,"function":"(*producer).Produce.func1"},{"file":
>> "/usr/local/go/src/runtime/asm_amd64.s","line":573,"function":"call32"},{
>> "file":"/usr/local/go/src/runtime/panic.go","line":502,"function":
>> "gopanic"},{"file":"/usr/local/go/src/runtime/panic.go","line":63,
>> "function":"panicmem"},{"file":"/usr/local/go/src/runtime/signal_unix.go"
>> ,"line":388,"function":"sigpanic"},{"file":
>> "/usr/local/go/src/unicode/utf8/utf8.go","line":483,"function":
>> "ValidString"},{"file":"/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":2074,"function":"appendUTF8StringValueNoZero"},{"file":"/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":270,"function":"(*marshalInfo).marshal"},{"file":"/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":2264,"function":"makeMessageSliceMarshaler.func2"},{"file":
>> "/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":270,"function":"(*marshalInfo).marshal"{"file":"/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":2234,"function":"makeMessageMarshaler.func2"},{"file":"/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":270,"function":"(*marshalInfo).marshal"},{"file":"/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":141,"function":"(*InternalMessageInfo).Marshal"},{"file":
>> "/go/src/github.com/carousell/Cats/Cats/Cats_proto/analytics.pb.go",
>> "line":447,"function":"(*AdRequestMsg).XXX_Marshal"},{"file":"/go/src/
>> github.com/carousell/Cats/vendor/github.com/golang/protobuf/proto/table_marshal.go
>> ","line":2715,"function":"Marshal"}]
>>
>>
>  Have omitted the initial part of the stack trace. Can someone tell me 
> when all could this happen ? Could it be because of a difference in 
> protobuf library versions ? I am unable to get the message, as when the 
> panic happens when the serialization is taking place. Any ideas on how to 
> approach this kind of 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/eb43e86c-b595-4ae7-8a9b-a6645bc013e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: godoc memory leak

2019-06-18 Thread Agniva De Sarker
I can see that files are getting added. Which means index size is expected
to increase. But it seems sometimes it is increasing even when there is no
change.

Could you please file an issue so that folks can investigate this ? Thanks.

On Tue, Jun 18, 2019, 10:17 PM Christopher Dang 
wrote:

> Hello Agniva,
>
> Here is the information you've asked for:
>
> go version: 1.12.0
> godoc version: latest
>
> I don't read from an index file because I need live updating from godoc
> and boot time isn't a high priority. This is because the service I'm
> creating can expect many files to be added, removed, or updated while godoc
> is running. While it would be convenient to restart godoc between file
> system changes my superiors would prefer I not use this option.
>
> I've attached a log dump from godoc -v below.
>
> I'm running the godoc process from within a docker so I use three methods
> to measure the memory usage:
> 1.) I docker exec into the container and run *top. *The *VSZ% *is the
> stat I use to measure memory from inside the docker.
> 2.) I run *docker stats* on the container from my host process
> 3.) since I run godoc with the verbose flag I get logs that tell me how
> many bytes are consumed by godoc. Example:
> 2019/06/17 23:28:26 index updated (88.264700559s, 211342912 bytes of
> source, 17421 files, 6533095 lines, 173980 unique words, 8997500 spots)
> 2019/06/17 23:28:26 before GC: bytes = 2385978984 *footprint* = 6429047608
> 2019/06/17 23:28:26 after  GC: bytes = 614368968* footprint *= 6429047608
>
> The charts and excel sheet above get their data points from godoc's
> footprint logs. I double check every now and then that footprint's output
> is accurate by comparing it against *top* and *docker stats. *
>
> The docker image is golang:1.12.0-alpine3.9
>
> On Mon, Jun 17, 2019 at 9:40 PM Agniva De Sarker <
> agniva.quicksil...@gmail.com> wrote:
>
>> Couple of questions:
>>
>> 1. What version of godoc and Go are you using ? What is your go env ?
>>
>> 2. You are using -index but not passing an index file. Any reason for
>> that ? godoc will load faster if you write an index beforehand and pass
>> that.
>>
>> 3. I am guessing since you have set index_interval, you expect files to
>> be added in your GOPATH. How many new files are getting added while godoc
>> is running ?
>>
>> 4. Please show us the output by adding -v flag.
>>
>>
>>
>> On Tuesday, 18 June 2019 05:28:39 UTC+5:30, christo...@wework.com wrote:
>>>
>>> Hi all,
>>>
>>>
>>> I've been playing around with an internal godoc server and noticed that
>>> over long periods of time the memory growth is unbounded. The command I use
>>> to invoke godoc is *godoc -index=true -index_interval=15m
>>> -index_throttle=.30 -maxresults=0*. The following images below track
>>> the memory usage and change in memory usage over a 24 hour period on a 8
>>> GiB machine. I've also attached a pdf with the data points I gathered
>>> during the experiment. Notice how the godoc process consumes 76% of memory
>>> by the end of the experiment. Is this indicative of a memory leak in the
>>> godoc source code or is this expected behavior?
>>>
>>>
>>> [image: Δ Mem Usage %.png][image: Mem Usage %.png]
>>>
>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/nU706aM7QpM/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/60b70a8c-3a3d-49c6-b9dc-b2bd1053c435%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/60b70a8c-3a3d-49c6-b9dc-b2bd1053c435%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOpCn4hCCSsnCq%3DG%3DAfAA4J7_TVjRo2rT3Z35YDG2VWXAsJVjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: godoc memory leak

2019-06-17 Thread Agniva De Sarker
Couple of questions:

1. What version of godoc and Go are you using ? What is your go env ?

2. You are using -index but not passing an index file. Any reason for that 
? godoc will load faster if you write an index beforehand and pass that.

3. I am guessing since you have set index_interval, you expect files to be 
added in your GOPATH. How many new files are getting added while godoc is 
running ?

4. Please show us the output by adding -v flag.



On Tuesday, 18 June 2019 05:28:39 UTC+5:30, christo...@wework.com wrote:
>
> Hi all,
>
>
> I've been playing around with an internal godoc server and noticed that 
> over long periods of time the memory growth is unbounded. The command I use 
> to invoke godoc is *godoc -index=true -index_interval=15m 
> -index_throttle=.30 -maxresults=0*. The following images below track the 
> memory usage and change in memory usage over a 24 hour period on a 8 GiB 
> machine. I've also attached a pdf with the data points I gathered during 
> the experiment. Notice how the godoc process consumes 76% of memory by the 
> end of the experiment. Is this indicative of a memory leak in the godoc 
> source code or is this expected behavior?
>
>
> [image: Δ Mem Usage %.png][image: Mem Usage %.png]
>
>
>

-- 
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/60b70a8c-3a3d-49c6-b9dc-b2bd1053c435%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Test a Golang API on the web

2019-05-28 Thread Agniva De Sarker
I think the Heroku free tier is a great tool for this. 

On Monday, 27 May 2019 20:01:38 UTC+2, aimar wrote:
>
> Hi,
>
> My teacher has asked me to develop an API with Golang and test it on the 
> web instead of localhost. I was thinking of github.io but then I figured 
> out, it doesn't support server-side languages and just support static 
> pages. Would you please let me know, if there is any platform which I can 
> test my API online rather than localhost? (for free, of course) 
> It is worth to mention my API generally generates just a couple of strings 
> from a JSON file, thus it does not need a database.
>
> thanks,
> Aimar
>

-- 
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/68fa924c-3986-4f4c-94ef-6f3af595710b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Go documentation - how to determine what implements an interface?

2019-05-16 Thread Agniva De Sarker
godoc _is_ the tool serving golang.org (Although now it's split into 2). 
You just need to enable that flag to get the results you want. Enabling it 
by default in golang.org is https://github.com/golang/go/issues/11251. Feel 
free to subscribe to that.

On Thursday, 16 May 2019 10:15:56 UTC+2, White Hexagon wrote:
>
> Thanks. Tools are fine, but a new developer has to know about them.  So I 
> think it would still be super useful if golang.org documentation had this 
> information already generated.  In bytes.Reader I should be able to see 
> 'Implements ReadSeeker etc', and in ReadSeeker I should be able to see 
> 'Implemented by bytes.Reader etc'.
>
> Cheers
> Peter
>
> On Thursday, 16 May 2019 09:50:04 UTC+2, Agniva De Sarker wrote:
>>
>> You can see the documentation by enabling type analysis in godoc. See 
>> https://golang.org/lib/godoc/analysis/help.html. Also see 
>> https://github.com/golang/go/issues/20131
>>
>>

-- 
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/e0dac7d1-1e2b-4278-94b8-1c6c0b30b7c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Go documentation - how to determine what implements an interface?

2019-05-16 Thread Agniva De Sarker
You can see the documentation by enabling type analysis in godoc. 
See https://golang.org/lib/godoc/analysis/help.html. Also 
see https://github.com/golang/go/issues/20131

On Wednesday, 15 May 2019 22:28:46 UTC+2, White Hexagon wrote:
>
> bytes.Reader is what I was looking for, thanks all!
>
> Seems like if it this information can be generated, then it should 
> probably be included in the main documentation?  I don't know how anyone 
> new to the language would ever work that out otherwise.
>
> I have vscode 1.33, which support guru (using .0.9.2 of the go tools), but 
> I don't see the option for 'implements'.
>
> macos 10.12.4
> go 1.12.5
>
> Cheers
> Peter
>

-- 
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/ba16f2d7-203b-45e5-952b-ab5e1bacd4b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: WASM persistent storage

2019-05-13 Thread Agniva De Sarker
As of now, it is open for anybody to investigate and work on it. Until 
then, calling JS is the best way to go.

-Agniva

On Monday, 13 May 2019 02:37:16 UTC+2, Luis Furquim wrote:
>
> Hello Agniva!
>
> Thanks for the clarification! If I clearly understood the discussion on 
> that issue, there is no current work to implement file I/O nor there are 
> plans to do it in the near future. Do I understand it correctly? If so, the 
> solution should be calling JS to persist the data?
>
> Again, thanks for your attention,
> Luis Otavio
>
> Em domingo, 12 de maio de 2019 19:22:01 UTC-3, Agniva De Sarker escreveu:
>>
>> There is no file I/O in the browser using Go wasm yet. Please see 
>> https://github.com/golang/go/issues/26051
>>
>> On Sunday, 12 May 2019 13:56:49 UTC+2, Luis Furquim wrote:
>>>
>>> Hello,
>>>
>>> Is it possible to persist files when using Golang/WASM on a browser? I 
>>> found this page 
>>> https://uncovergame.com/2015/06/06/persisting-data-with-emscripten/ 
>>> showing explaining how to do it using C+EMScripten, but I couldn't find an 
>>> example or documentation in Go. The page doesn't explicit if it does it 
>>> through wasm, but I think it is implied. If it is really possible, someone 
>>> knows how to do it from Go and point me to some documentation?
>>>
>>> Thank you in advance.
>>>
>>> -- 
>>> Luis Otavio de Colla Furquim
>>>
>>>

-- 
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/cc957d51-744b-4538-86e5-8406f4dea51b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: WASM persistent storage

2019-05-12 Thread Agniva De Sarker
There is no file I/O in the browser using Go wasm yet. Please 
see https://github.com/golang/go/issues/26051

On Sunday, 12 May 2019 13:56:49 UTC+2, Luis Furquim wrote:
>
> Hello,
>
> Is it possible to persist files when using Golang/WASM on a browser? I 
> found this page 
> https://uncovergame.com/2015/06/06/persisting-data-with-emscripten/ 
> showing explaining how to do it using C+EMScripten, but I couldn't find an 
> example or documentation in Go. The page doesn't explicit if it does it 
> through wasm, but I think it is implied. If it is really possible, someone 
> knows how to do it from Go and point me to some documentation?
>
> Thank you in advance.
>
> -- 
> Luis Otavio de Colla Furquim
>
>

-- 
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/8551efab-297f-4c95-a9ee-80fe016a11f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Help wanted - ReferenceError: Go is not defined error

2019-04-06 Thread Agniva De Sarker
Remove the async attribute from your script tag.

On Saturday, 6 April 2019 23:38:17 UTC+5:30, jon.ki...@gmail.com wrote:
>
> I am new to Go programming.  I stumbled across a project for using 
> WeAssembly at https://github.com/golang/go/wiki/WebAssembly and decided 
> to give it a try.  So I'm running a test website on the Google App Engine, 
> and the website is running on Go.  I created all the objects according to 
> the documentation provided on the page, but every time I run the website, I 
> get this error in the console:  Uncaught ReferenceError: Go is not defined
>
> I'm expecting to see "Hello World" in the console of the browser, but 
> instead I get the above error.  I'm sure it's pointing to the section 
> "const go = new Go();", but I'm not sure why I'm getting this error.  I'm 
> running the latest version on Chrome on Win10.  The test website is at 
> https://test-rest-api-236401.appspot.com/ currently running the code 
> giving me the error.  I've tried simplifying it based on other pages also 
> pointing to WASM documentation, but I keep getting the same error.  I've 
> done extensive searching and I've not seen anyone get this particular 
> error.  Please help.  What am I missing?
>
> Here's how the source is laid out on the page:
> I'm currently running Go 1.12
>
> /app.yaml  --used to run the website
> /index.html  -- used to run the website and init the wasm go code
> /main.go  -- used to run the website
> /static/cmd/test.wasm   -- my compiled wasm hello world go code
> /static/cmd/test.go  -- I don't believe I actually need this here since I 
> have the .wasm file there.  I've tried it with and without it and still get 
> the error.
> /static/scripts/wasm_exec.js  -- version is the latest from the 1.12 
> source, but I've alternatively tried older versions from 1.11.x
>
>
>
>

-- 
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: wasm output and modules

2019-03-28 Thread Agniva De Sarker
> I'm using a wait on a Go chan, and using a defer to Release allocated 
FuncOf methods. Am I missing anything else? 

Are you signalling the chan to exit ? Unless that happens, those Funcs will 
not be released. Typically, you have an "exit" button which is hooked to an 
event listener that signals your main goroutine to exit, cleaning up its 
resources.

Regarding restart, just use JS to call go.run() again, once you have exited 
from it. Reuse the result.instance by storing it in a variable. I think 
that should do it. 

On Wednesday, 27 March 2019 12:49:48 UTC+5:30, whiteh...@googlemail.com 
wrote:
>
> Thanks.  So those flags knocked about 100kB off the size down to 2.5MB.  
> But it seems Kotlin generates a similar sized file ~2.6MB maybe for a 
> similar reason i.e. runtime jvm.
>
> I also tried gzip as suggested on the wiki, but my hosting provider always 
> delivers the full file :(
>
> But anyway my hosting provider has added support for the application/wasm  
> MIME type now :) and I'm now able to use the following to start the app:
>
> 
> const go = new Go();
> WebAssembly.instantiateStreaming(fetch("app.wasm"), go.importObject).then(
> async (result) => {
> await go.run(result.instance);
> });
> 
>
> I'm, wondering if there is anything special I need to do to 'cleanup' the 
> wasm afterwards.  because this runs fine on macos, but doesnt seem to run a 
> second time on win7 firefox 65 box without restarting the browser.
>
> I'm using a wait on a Go chan, and using a defer to Release allocated 
> FuncOf methods. Am I missing anything else? 
>
> Thanks, Peter
>
>
>
> On Wednesday, 27 March 2019 05:42:04 UTC+1, Agniva De Sarker wrote:
>>
>> You can use "-ldflags='-s -w'" to reduce the size, but it is expected 
>> that wasm files will be in the order of MBs (see 
>> https://golang.org/doc/go1.11#wasm). 
>>
>> > So I was wondering if there are tools that parse the .wasm and prune 
>> unused pkgs?
>>
>> The size is not due to unused packages being imported, but rather the 
>> runtime and scheduling code. See the relnotes above.
>>
>>

-- 
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: wasm output and modules

2019-03-26 Thread Agniva De Sarker
You can use "-ldflags='-s -w'" to reduce the size, but it is expected that 
wasm files will be in the order of MBs (see 
https://golang.org/doc/go1.11#wasm). 

> So I was wondering if there are tools that parse the .wasm and prune 
unused pkgs?

The size is not due to unused packages being imported, but rather the 
runtime and scheduling code. See the relnotes above.

On Tuesday, 26 March 2019 17:45:08 UTC+5:30, whiteh...@googlemail.com wrote:
>
> I know that the Go wasm support is still experimental, although it seems 
> to be working great here! :) but are there any tools for pruning the .wasm 
> output?  I'm only using about 3 pkg imports but end up with a 2.6MB .wasm 
> file.  I've seen the suggestion for using tinygo, but I didnt get that 
> working here...  
>
> So I was wondering if there are tools that parse the .wasm and prune 
> unused pkgs?  
>
> Or are there plans to add any pruning to Go core?  So far I saw the file 
> size increase between 1.11 and 1.12...
>
> Also, from what I've read about wasm so far, there is some support for 
> modules.  Which to me sounds like one wasm module should be able to talk to 
> another wasm module directly, avoiding the js bridge.  Does Go in anyway 
> support this concept, or have I misunderstood it?
>
> Thanks, Peter
>
> macos10.12.4, Go 1.12
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: How to use godoc with Go's module?

2019-03-26 Thread Agniva De Sarker

godoc doesn't work in module mode yet. The workaround is to create a 
directory resembling a GOPATH and put your project there and set the GOPATH 
variable to that.

Tracking issue here - https://github.com/golang/go/issues/26827

On Tuesday, 26 March 2019 18:07:23 UTC+5:30, Weerasak Chongnguluam wrote:
>
> I try to use `godoc` to render package's documentation of module. But 
> `godoc` parsing only packages in `GOPATH`. How to use `godoc` with Go's 
> module or have alternative tool to render document of Go's module?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] How to lower listen backlog for tcp socket

2019-03-22 Thread Agniva De Sarker
Oh I see. Then this is a linux networking question rather than a Go 
question. I know there are sysctl settings for that. But offhand, I am not 
aware of the code for it using socket options.

On Friday, 22 March 2019 22:19:26 UTC+5:30, Peter Wang wrote:
>
> I know Control func and syscall.SetsockoptInt(fd, syscall.AF_INET, 
> syscall.SO_REUSEADDR, 1)  cat set reuseadd
> But how to adjust listen backlog since i never find socket options for it.
>
> Agniva De Sarker > 于2019年3月22日周五 
> 下午4:44写道:
>
>> Using ListenConfig is the way to go.
>>
>> The Control func is passed the raw socket connection on which you can 
>> apply whatever socket options you choose. You have to go through 2 layers 
>> to get to the fd.
>>
>> ListenConfig{
>>  Control: func(conn syscall.RawConn) error { 
>>return conn.Control(func(fd uintptr) error { 
>>  return syscall.SetsockoptInt(fd, syscall.AF_INET, 0, 0) 
>>}) 
>>   } 
>> }
>>
>>
>> On Thursday, 21 March 2019 20:49:20 UTC+5:30, Peter Wang wrote:
>>>
>>> I try to use net.ListenConfig, but fail
>>> can someone give example ?
>>>
>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] How to lower listen backlog for tcp socket

2019-03-22 Thread Agniva De Sarker
Using ListenConfig is the way to go.

The Control func is passed the raw socket connection on which you can apply 
whatever socket options you choose. You have to go through 2 layers to get 
to the fd.

ListenConfig{
 Control: func(conn syscall.RawConn) error { 
   return conn.Control(func(fd uintptr) error { 
 return syscall.SetsockoptInt(fd, syscall.AF_INET, 0, 0) 
   }) 
  } 
}


On Thursday, 21 March 2019 20:49:20 UTC+5:30, Peter Wang wrote:
>
> I try to use net.ListenConfig, but fail
> can someone give example ?
>
>

-- 
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: [ANN] Official Go client for Elasticsearch

2019-02-08 Thread Agniva De Sarker
Much appreciated :)

On 2/8/19, Karel Minařík  wrote:
> It is definitely on the priorities list. The API itself is generated, so
> it's a matter of adjusting potential edge cases, and a bit of
> administration around branches/tags.
>
> Karel
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/2fqVs9XgIGI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Is WASM support planned in go 1.12 ?

2019-02-08 Thread Agniva De Sarker
To add to what Keith has said, Callback has been renamed to Func because 
the function will get called synchronously instead of being async. This is 
one of the major changes in 1.12.


On Thursday, 7 February 2019 05:11:50 UTC+5:30, Keith Randall wrote:
>
> To answer the OP, wasm support is in 1.12 and is still experimental. There 
> have been some changes to the wasm support but nothing major. (See the 
> syscall/js section of https://tip.golang.org/doc/go1.12 for details.)
>
> On Wednesday, February 6, 2019 at 2:27:53 PM UTC-8, Tharaneedharan 
> Vilwanathan wrote:
>>
>> Thanks, Russtopia and Ian!
>>
>> On Wed, Feb 6, 2019 at 1:07 PM Ian Denhardt  wrote:
>>
>>> Quoting Tharaneedharan Vilwanathan (2019-02-06 15:30:51)
>>>
>>> >Somehow I was dreaming I can use Go for frontend too, instead of 
>>> JS. Is
>>> >my thinking right?
>>>
>>> If that's your interest use gopherjs instead:
>>>
>>> https://github.com/gopherjs/gopherjs
>>>
>>> It's been around a long time and is pretty mature.
>>>
>>> As others have said, talking to the DOM in wasm is clumsy at best (and
>>> there's nothing Go-specific about this). If you want to make significant
>>> use of browser APIs, Javascript is a better target.
>>>
>>> -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: [ANN] Official Go client for Elasticsearch

2019-02-08 Thread Agniva De Sarker
Great stuff !

> The client targets Elasticsearch 7.x. Support for 6.x and 5.x APIs will 
be added later.

Would appreciate if this is prioritized. Our ES setup use 5.x version. We 
would be unable to use this client if it does not support 5.x.

On Friday, 8 February 2019 16:03:37 UTC+5:30, Karel Minařík wrote:
>
> Hi all,
>
> a new official Go client for Elasticsearch has been published to Github 
> today:
>
> —> https://github.com/elastic/go-elasticsearch
>
> The client has been in the works for couple of months, and completely 
> replaces the old "WIP" client in the repository.
>
> The project comes with extensive documentation and examples:
>
> * https://godoc.org/github.com/elastic/go-elasticsearch
> * https://github.com/elastic/go-elasticsearch/tree/master/_examples
>
> Feedback is very welcome through the list or Github issues!
>
> Karel
>
>

-- 
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: WebAssembly: Auto-generating Go bindings for javascript/DOM from the Web Standards.

2018-12-28 Thread Agniva De Sarker
Makes sense. This has been brought up before in the #webassembly channel. 
Don't remember what the conclusion was. But please feel free to drop in and 
throw some ideas around.

Demand for a proper DOM API has been growing. And I think auto-generating 
from WebIDL files are a great way to get started.


On Friday, 28 December 2018 17:46:22 UTC+5:30, Chris FractalBach wrote:
>
> This is in the context of compiling Go to webassembly that will be used 
> with javascript.
>
>
> *Currently:*
>
> We have`syscall/js` which has stuff like this:
> ```go
> js.Global().Get("document").Call("createElement", "div")
> ```
>
> What it could be:
> ```go
> js.document.createElement("div")
> ```
>
>
>
> *Why?*
>
> This would make writing stuff for webassembly WAY easier.
> Auto-generating it would allow it to update definitions whenever the 
> standards
> are updated.  Which would make it easier to maintain.
>
> Also, if there's going to be significant usage of
> Go -> webassembly -> web browser and javascript
> then having all the types and definitions auto-generated would save on tons
> of boilerplate abstractions that people will inevitably create for their 
> own sanity.
>
> Advantages:
> - more natural to use
> - more readable
> - type safe
>
> Disadvantages:
> - less flexible
> - when the APIs are updated, it might result in loss of 
> backwards-compatibility
>
>
>
>
> *How?*
>
> WebIDL --> Go source code
>
> - https://www.w3.org/TR/WebIDL/
> - https://heycam.github.io/webidl/
> - https://www.w3.org/TR/DOM-Level-3-Core/idl-definitions.html
>
>
>
>
> Technical reports published by the W3C that include programming language 
>> interfaces have typically been described using the Object Management 
>> Group’s Interface Definition Language (IDL) [OMGIDL]. The IDL provides a 
>> means to describe these interfaces in a language independent manner. 
>> Usually, additional language binding appendices are included in such 
>> documents which detail how the interfaces described with the IDL correspond 
>> to constructs in the given language.
>
> https://www.w3.org/TR/WebIDL/#introduction
>
>
>
>
>
> *A Possible Conversion:*
>
> *From WebIDL:*
> ```
> [Exposed=Window]
> interface Paint { };
>
>
> [Exposed=Window]
> interface SolidColor : Paint {
>   attribute double red;
>   attribute double green;
>   attribute double blue;
> };
>
>
> [Exposed=Window]
> interface Pattern : Paint {
>   attribute DOMString imageURL;
> };
>
>
> [Exposed=Window, Constructor]
> interface GraphicalWindow {
>   readonly attribute unsigned long width;
>   readonly attribute unsigned long height;
>
>
>   attribute Paint currentPaint;
>
>
>   void drawRectangle(double x, double y, double width, double height);
>
>
>   void drawText(double x, double y, DOMString text);
> };
>
> ```
> Example From: https://heycam.github.io/webidl/
>
>
>
> *To Go:*
>
> This is probably not the best way to do it, but is an example of how it 
> might look.
>
> type Paint struct {}
>
>
> type SolidColor struct {
>  Red   float64
>  Green float64
>  Blue  float64
> }
>
>
> type GraphicalWindow struct {
>  widthuint32
>  height   uint32
>  CurrentPaint Paint
> }
>
>
> func (gw *GraphicalWindow) drawRectangle(x, y, width, height float64) {
> // syscall
> }
>
>
> func (gw *GraphicalWindow) drawText(x, y float64, text string) {
> // syscall
> }
>
>
>
>
>
>
> I know there are some existing examples of Go bindings for DOM, 
> but I don't think they are auto-generated from WebIDL,
> Which I imagine would be easier to maintain in the long-run.
>
>
>
>
> Anybody have thoughts on this?
>
>
>
>
>

-- 
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] When set time.Location, will be detected Data Race

2018-11-30 Thread Agniva De Sarker
Can you show us the code ? It would help 

Are you trying to set a variable of type time.Location ? Or are you trying 
to set time.Local to something else ?

Like Ian said, if you want to change the location of a specific time value, 
use the In method.

> But there are lots of place that time.Location used by time package of 
golang. For example: time.Now(), time.locabs()

> I can’t change them.
I don't understand. Use time.Now() uses the time.Local variable. But all 
you need to do is wrap the setting of time.Local value with a mutex. Why is 
it not possible to do that ?




On Friday, 30 November 2018 11:31:42 UTC+5:30, Ian Lance Taylor wrote:
>
> On Thu, Nov 29, 2018 at 9:47 PM > 
> wrote: 
> > 
> > My go version is 1.11. 
> > 
> > When I set time.Location, then … 
> > 
> > == 
> > WARNING: DATA RACE 
> > Write at 0x02e275d0 by main goroutine: 
> >   vcs.taiyouxi.net/platform/planx/timeutil.SetTimeLocal() 
> >   /Users/zhangzhen/serverthreekingdom/src/
> vcs.taiyouxi.net/platform/planx/timeutil/time_util.go:51 +0xb4 
> >   vcs.taiyouxi.net/platform/planx/timeutil.init.0() 
> >   /Users/zhangzhen/serverthreekingdom/src/
> vcs.taiyouxi.net/platform/planx/timeutil/time_util.go:42 +0x43 
> >   vcs.taiyouxi.net/platform/planx/timeutil.init() 
> >   :1 +0xd0 
> >   vcs.taiyouxi.net/jws2/common/time.init() 
> >   :1 +0xa6 
> >   vcs.taiyouxi.net/jws2/gamex/account/account.init() 
> >   :1 +0xa6 
> >   vcs.taiyouxi.net/jws2/gamex/logics.init() 
> >   :1 +0xa6 
> >   vcs.taiyouxi.net/jws2/gamex/cmds/gamemode.init() 
> >   :1 +0xa6 
> >   main.init() 
> >   :1 +0xa6 
> > 
> > Previous read at 0x02e275d0 by goroutine 8: 
> >   time.Now() 
> >   /Users/zhangzhen/.gvm/gos/go1.11/src/time/time.go:1060 +0xcf 
> >   time.sendTime() 
> >   /Users/zhangzhen/.gvm/gos/go1.11/src/time/sleep.go:141 +0x44 
> > 
> > Goroutine 8 (running) created at: 
> >   runtime.(*timersBucket).addtimerLocked() 
> >   /Users/zhangzhen/.gvm/gos/go1.11/src/runtime/time.go:170 +0x113 
> >   
> vcs.taiyouxi.net/vendor/github.com/siddontang/go/timingwheel.NewTimingWheel() 
> >   /Users/zhangzhen/serverthreekingdom/src/
> vcs.taiyouxi.net/vendor/github.com/siddontang/go/timingwheel/timingwheel.go:39
>  
> +0x2a0 
> >   vcs.taiyouxi.net/platform/planx/util.init() 
> >   /Users/zhangzhen/serverthreekingdom/src/
> vcs.taiyouxi.net/platform/planx/util/timer_helper.go:10 +0xf3 
> >   vcs.taiyouxi.net/platform/planx/metrics.init() 
> >   :1 +0xbf 
> >   vcs.taiyouxi.net/jws2/gamex/cmds/gamemode.init() 
> >   :1 +0x9c 
> >   main.init() 
> >   :1 +0xa6 
> > == 
> > 
> > The feature of golang is goroutine, and it is a normal situation that 
> get time in different goroutine. 
> > But only can set time.Location in one goroutine. So the Data Race is 
> inevitable. 
> > 
> > 
> > And there is the replay from agnivade 3 
> > 
> > “It is not a bug. Please synchronize access to time.Location using 
> synchronization primitives in the sync andsync/atomic packages.” 
> > 
> > 
> > But there are lots of place that time.Location used by time package of 
> golang. For example: time.Now(), time.locabs() 
> > I can’t change them. 
> > 
> > 
> > So, What should I do ? Please help me. 
>
> You said time.Location.  Do you mean time.Local?  It's true that you 
> should never change time.Local.  Why  do you want to?  If you want to 
> change the location of a specific time.Time value, call the In method. 
>
> 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: Why can't I see the whole stack trace of goroutine

2018-11-08 Thread Agniva De Sarker
Have you tried Ctrl+\ ? That should dump all the goroutines. It also closes 
the app.

If you don't want the app to shut down, then you can take a goroutine 
profile - https://golang.org/pkg/runtime/pprof/#Profile. 

On Wednesday, 7 November 2018 09:25:24 UTC+5:30, rickyu...@gmail.com wrote:
>
> I have a lot of leaking goroutines in my code over a span of time. I am 
> trying to debug it but I can't seem to figure out from where these are 
> occuring from.
> Any help in finding the source is helpful.
>
>
> goroutine 2329 [select, 1281 minutes]:
> net/http.(*persistConn).readLoop(0xc420a80120)
>   /usr/local/go/src/net/http/transport.go:1599 +0x9ec
> created by net/http.(*Transport).dialConn
>   /usr/local/go/src/net/http/transport.go:1117 +0xa35
>
>
> 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: net/http ReadRequest gives empty URL for valid HEAD request

2018-10-25 Thread Agniva De Sarker
Does not look like a valid HEAD request. It should be "HEAD / HTTP/1.1"

-Agniva

On Friday, 26 October 2018 00:15:14 UTC+5:30, Swapnil Mhatre wrote:
>
> Hi,
>
> I wanted to check on the forum first before filing an issue. Please see 
> below for the issue I am seeing.
> I used a valid POSTMAN HTTP HEAD request message for my test.
>
>
> ### What version of Go are you using (`go version`)?
> go 1.11
>
> ### Does this issue reproduce with the latest release?
> Don't know
>
> ### What operating system and processor architecture are you using (`go 
> env`)?
>
> GOARCH="amd64"
> GOBIN="~/go/bin"
> GOCACHE="~/Library/Caches/go-build"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="~/go"
> GOPROXY=""
> GORACE=""
> GOROOT="/usr/local/Cellar/go/1.11/libexec"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
> GCCGO="gccgo"
> CC="clang"
> CXX="clang++"
> CGO_ENABLED="1"
> GOMOD=""
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 
> -fdebug-prefix-map=/var/folders/xq/88glw72j3ynbq5_j7x5sgvxnpx11yg/T/go-build829540991=/tmp/go-build
>  
> -gno-record-gcc-switches -fno-common"
>
>
> ### What did you do?
> func main() {
> _, err := http.ReadRequest(bufio.NewReader(strings.NewReader("HEAD  
> HTTP/1.1\nHost: www.google.com\nCache-Control: no-cache\nPostman-Token: 
> 607a1d46-4142-ccf9-b914-68332013ca14")))
> fmt.Println(err.Error())
> }
>
> If possible, provide a recipe for reproducing the error.
> A complete runnable program is good.
> A link on play.golang.org is best.
>
>
> ### What did you expect to see?
> The request string is a valid HEAD request copied from POSTMAN REST client 
> and the HEAD request returns a 200 OK
> You can use any HEAD request message.
>
> ### What did you see instead?
>
> http.ReadRequest failed to parse the request and gave an empty url error
> parse : empty url
>
>
> Thanks,
> Swapnil
>
>

-- 
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: Go standard library documentation for older Go versions

2018-10-16 Thread Agniva De Sarker
Online API docs are just for the latest release and the master branch. But 
if you have the version you want locally installed, you can just spin up 
godoc and point to the goroot and browse it.

> I would love it if the https://golang.org/pkg/ documentation had 
"introduced in version..." notations 

It already does. Example - https://golang.org/pkg/net/http/#SameSite



On Tuesday, 16 October 2018 20:08:10 UTC+5:30, aco...@redhat.com wrote:
>
> I have not been able to find online API doc for older Go standard library 
> versions, where would I find this? Apologies if it's in an obvious place 
> and I missed it.
>
> I would love it if the https://golang.org/pkg/ documentation had 
> "introduced in version..." notations like https://docs.python.org or 
> https://en.cppreference.com - but I'll settle for easy access to docs for 
> older versions.
>
> Minor nit: the release notes in the release history link to 
> https://golang.org/pkg/ which is not really correct. The latest version 
> could have made further changes to the API since that release which would 
> be confusing.
>
>

-- 
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] net.TCPConn equivalent for setsockopt

2018-10-01 Thread Agniva De Sarker


On Tuesday, 2 October 2018 04:30:54 UTC+5:30, Robert Engels wrote:
>
>
> On Oct 1, 2018, at 4:59 PM, Ian Lance Taylor  > wrote:
>
> On Mon, Oct 1, 2018 at 1:53 PM, robert engels  > wrote:
>
>
> If you go to the TCPConn SetReadDeadline function, it states “implements 
> the Conn SetReadDeadline method”, with no way of referencing the 
> documentation for Conn.SetReadDeadline, in fact, no way of even getting to 
> the Conn interface… who knows what Conn is ??? Assume it is a Conn returned 
> by Dial? How do you determine this?
>
>
> You're right, that is kind of useless.  Would you mind filing an issue
> about that?  It should be fixed one way or another.
>
>
> I will do so.
>
>
> There are already issues filed to track all of these. 

https://github.com/golang/go/issues/25444
https://github.com/golang/go/issues/20131
https://github.com/golang/go/issues/5860

>
> Furthermore, it is not completely specified, meaning if the read timeout 
> occurs, and some data was read, is it discarded? will it be returned with 
> the next read (if any)? Doesn’t say...
>
>
> The behavior of the standard Read method when an error occurs is
> documented by the io.Reader interface.
>
>
> But that is kind of the problem, without an ‘implements’ keyword, I would 
> think that the documentation needs to be specify exactly what interfaces it 
> “implements”. How do I KNOW that the read on on UDP connection is intended 
> to be an io.Reader ? It may be “self evident” for the “stdlib” interfaces, 
> or the de-facto expected behavior, but it gets far trickier when the 
> interface is not a standard one.
>
> If Go doesn’t have (or want), “implements”, there needs to be a way for 
> the documentation to declare the ‘implemented’ interfaces as expected by 
> the author.
>
> For example, here is the documentation for UDPConn:
>
> UDPConn is the implementation of the Conn and PacketConn interfaces for 
> UDP network connections.
>
> type UDPConn struct {
> // contains filtered or unexported fields
> }
>
> Again, which Conn, and which PacketConn, and if I have a Conn, and look at 
> the (net.Conn) interface (below) it doesn’t state the Read method functions 
> according to the io.Reader interface anywhere that I can determine...
>
> // Read reads data from the connection.
> // Read can be made to time out and return an Error with Timeout() == true
> // after a fixed time limit; see SetDeadline and SetReadDeadline.
> Read(b []byte) (n int, err error)
>
>
>
> Maybe I am looking at it wrong, but I think Go’s “simplicity” cannot be 
> extended to the specifications, especially when dealing with low-level 
> networking, api, etc. It makes it very difficult to use, and be able to 
> guarantee it will work the same on all platforms - hurting the portability.
>
>
> I'm not really sure what you're thinking of here.
>
>
> Pretty much inline with the previous sentiment. I just got done writing 
> the LRMP protocol project, and I’ve done a LOT of networking code in many 
> languages and platforms, and doing it in Go was more of a pain than I think 
> it should of been. The documentation is just not ‘linked/reference’ in a 
> way that is needed when you have dynamic interfaces. For example, similar 
> problems with PacketConn - there are multiple PacketConn interfaces and it 
> is nearly impossible to figure out “what is what” by reading the 
> documentation. It often just states return a PacketConn, without a link to 
> the specific PacketConn . To further the example, if you work with 
> ipv4.PacketConn, is it a net.PacketConn? No way to know / see the hierarchy 
> with out coding it and looking for errors…. Very inefficient.
>
>
> 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.


Re: [go-nuts] Re: Updating a struct from goroutines

2018-09-27 Thread Agniva De Sarker
Sure, feel free to do what you are comfortable with. I just couldn't
understand why there is a need for the Update function at all.

Hope that your Go transition goes smoothly :)

-Agniva

On Thu, 27 Sep 2018 at 21:29 Michael Ellis 
wrote:

> Thanks for the feedback, Agni.  I think I may not have included enough
> detail in my original post.
>
> At present, the app is in the middle of transitioning to an all-Go
> implementation.  For business reasons, that process will be stretched out
> over the next several months or longer.  In the meantime, it needs to keep
> working so I've already implemented something quite similar to what you
> describe by porting the busiest Python processes first and providing a
> socket interface that replaces the ZeroMQ interface in a way that allows
> the calls from the remaining Python processes to have the same signature
> and behavior as before.  That's working quite well so far and we're already
> seeing better performance and improved reliability.
>
> I should also mention that the target for the system is an inexpensive
> Linux SBC, a Raspberry Pi.  In the pure Python version,  the overhead for
> serializing, transmitting and de-serializing data had grown to use far more
> CPU than seemed wise in a system that needs to run reliably for months at a
> time at customer sites around the world.
>
> Within the collection of processes that are now goroutines, I can't see a
> benefit to incurring the overhead to marshal and unmarshal the data if
> there's a concurrency-safe way to perform updates and get snapshots of the
> state data.
>
> Sending functions over a channel seems to be a match made in heaven for
> our use cases.  It nicely supports our application logic that parcels out
> responsibility for updating pieces of the state struct to long-running
> goroutines.  Most of them are loops that fetch a snapshot of the state,
> inspect it to make decisions about what actions to take, perform the
> actions and update the state.
>
> In that context, sending anonymous update functions wrapped in struct with
> a disposable "done" channel doesn't seem overcomplicated at all.  The
> update actions in my first post boil down to three lines that can be
> wrapped up in a single function, e.g.
>
> func Update(f func(*Big)) {
> u := update{make(chan struct{}), f}
> upch <- u // upch is a toplevel var visible to all goroutines
> <-u.done
> }
>
> and an (oversimplified) goroutine that, say, reads a new value from a
> sensor looks like
>
> func gopher() {
> var newA int
> f := func(b *Big) {
> b.A = newA
> }
> for {
> newA = ReadSensor()
> Update(f)
> }
> }
>
> As I see it, the beauties of this approach are:
>
>1.  f is locally defined and therefore has access to gopher's locals,
>2. gopher has no direct access to the instance of Big that holds the
>state.
>3. Update pauses gopher until the state update has completed in the
>single goroutine that reads from upch.  So no worries about gopher changing
>its own locals before the update is complete.
>4. Benchmarking shows it's more than fast enough for our needs.
>5. The compiler catches any type mismatches instead of depending on
>the runtime to report it at deserialization.
>
>
> Sorry for the long-winded reply. I really appreciate the feedback and the
> opportunity to learn from you and others who've been using Go far longer
> than I.
>
>
>
>
>
>
>
> On Thu, Sep 27, 2018 at 12:48 AM Agniva De Sarker <
> agniva.quicksil...@gmail.com> wrote:
>
>> I think you are overcomplicating this a bit. It seems like a simple
>> pattern of broadcasting a change to multiple agents. You send the change
>> over a REQ-REP pair, and broadcast it to others over a PUB-SUB pair.
>>
>> Why do you need to copy the struct again ? Just get the struct from the
>> REP socket and push it to the PUB socket ?
>>
>> Here is what I would do  -
>>
>> Use protobuf to marshal/unmarshal the config struct when
>> sending/receiving it through the socket. That way you have perfect interop
>> between Go and Python.
>>
>> And use a for-select pattern to do the job of receiving and broadcasting.
>> Pseudo code as follows
>>
>> package main
>>
>> func main() {
>> // setup REP socket in a goroutine, unmarshal the msg, send the struct to
>> updateChan
>> // create PUB socket, store it in mem somewhere
>>
>> go run()
>>
>> // setup signal handlers, and send signal to done chan when
>> ctrl-c is received.
>> }
>>
>> func run() {
>> for {
>&g

[go-nuts] Re: Updating a struct from goroutines

2018-09-26 Thread Agniva De Sarker
I think you are overcomplicating this a bit. It seems like a simple pattern 
of broadcasting a change to multiple agents. You send the change over a 
REQ-REP pair, and broadcast it to others over a PUB-SUB pair.

Why do you need to copy the struct again ? Just get the struct from the REP 
socket and push it to the PUB socket ?

Here is what I would do  -

Use protobuf to marshal/unmarshal the config struct when sending/receiving 
it through the socket. That way you have perfect interop between Go and 
Python.

And use a for-select pattern to do the job of receiving and broadcasting. 
Pseudo code as follows

package main

func main() {
// setup REP socket in a goroutine, unmarshal the msg, send the struct to 
updateChan
// create PUB socket, store it in mem somewhere

go run()

// setup signal handlers, and send signal to done chan when ctrl-c 
is received.
}

func run() {
for {
select {
case msg := <-updateChan:
// push msg to the PUB socket
case <-done:
// you have to send signal to this from main()
return
}
}
}

Isn't this what you are trying to do ?

 

On Wednesday, 26 September 2018 00:09:07 UTC+5:30, Michael Ellis wrote:
>
> Hi, new gopher here. 
> I considered asking this on SO, but they (rightly, IMO) discourage "Is 
> this a good way to do it?" questions.  Hope that's ok here.
>
> By way of background, I'm porting a largish industrial control application 
> from Python to Go.  The Python version uses multiple processes (about a 
> dozen in all) communicating over ZeroMQ.  One process, called the 
> statehouse,  controls access to the application state.  The others obtain 
> copies and send updates over REQ sockets.  The data are serialized as JSON 
> objects that map nicely to Python dicts.
>
> Since there's no direct equivalent in Go to a Python dict that can hold a 
> mixture of arbitrary types,  I need to use a struct to represent the state. 
> No problem with that but I've been struggling with how to allow the 
> goroutines that will replace the Python processes to read and write to the 
> state struct with concurrency safety.  
>
> This morning I came up with an idea to send functions over a channel to 
> the main routine.  I put together a little test program and after some 
> refinements it looks promising.  Some rough benchmarking shows I can get a 
> million updates in under 1 second on a 2012 vintage Mac Mini.  That's more 
> than good enough for this application where the time between events is 
> usually more than 100 milliseconds.
>
> Here's the link to my test on the Go Playground: 
> https://play.golang.org/p/8iWvwnqBNYl . It runs there except that the 
> elapsed time comes back 0 and the prints from the second goroutine don't 
> show up. I think that's got something to do with the artificial clock in 
> the playground.  It works fine when I run it locally.  I've pasted the code 
> at the bottom of this message.
>
> So my big questions are:
>
>- Is this actually concurrency safe as long as all goroutines only use 
>the update mechanism to read and write?
>- Is there a more idiomatic way to do it that performs as well or 
>better?
>- What are the potential problems if this is scaled to a couple dozen 
>goroutines?
>- Does it sacrifice clarity for cleverness? (not that it's all that 
>clever, mind you, but I need to think about handing this off to my 
> client's 
>staff.)
>
>
> Thanks very much,
> Mike Ellis
>
> code follows ... 
>
> package main
>
> import (
>  "fmt"
>  "time"
> )
>
>
> // Big defines the application's state variables
> type Big struct {
>  A int
>  B string
>  /* and hundreds more */
> }
>
>
> // update is a struct that contains a function that updates a Big and
> // a signal channel to be closed when the update is complete. An update
> // may also be used to obtain a current copy of a Big by coding f to
> // do so.  (See gopher2 below.)
> type update struct {
>  done chan struct{}
>  ffunc(*Big)
> }
>
>
> // upch is a channel from which main receives updates.
> var upch = make(chan update)
>
>
> // gopher defines a function that updates a member of a Big and
> // sends updates via upch. After each send it waits for main to
> // close the update's done channel.
> func gopher() {
>  var newA int
>  f := func(b *Big) {
>  b.A = newA
>  }
>  for i := 0; i < n; i++ {
>  newA = i
>  u := update{make(chan struct{}), f}
>  upch <- u
>  <-u.done
>  }
> }
>
>
> // gopher2 uses an update struct to obtain a current copy of a Big
> // every 100 microseconds.
> func gopher2() {
>  var copied Big
>  f := func(b *Big) {
>  copied = *b
>  }
>  for {
>  time.Sleep(100 * time.Microsecond)
>  u := update{make(chan struct{}), f}
>  upch <- u
>  <-u.done
>  fmt.Println(copied)
>  }
> }
>
>
> // main creates a Big, launches gopher and waits on the update channel. 
> When
> // an update, u, arrives it runs u.f and then closes u.done.
> func main() {
>  var state = Big{-1, "foo"}
>  fmt.Println(state) // --> {-1, "foo"}
>  go gopher()
>  go 

[go-nuts] Re: why does go reverse the order of name and type? "i int" vs "int i"

2018-09-20 Thread Agniva De Sarker
Here is your answer - https://tip.golang.org/doc/faq#declarations_backwards

On Thursday, 20 September 2018 11:00:11 UTC+5:30, Sathish VJ wrote:
>
> I've been asked this question a few times and I haven't been able to find 
> an answer.  Why does go reverse the order of variable declaration:  "i int" 
> vs "int i"
>
> Is there anything in the language design that requires this or was it 
> based on readability/writability or related to the parsing process or 
> something else?
>

-- 
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: Go Webassembly runs out of memory on Android

2018-09-18 Thread Agniva De Sarker
https://github.com/golang/go/issues/27462

On Tuesday, 18 September 2018 17:35:42 UTC+5:30, Tad Vizbaras wrote:
>
> Go Webassembly runs out of memory on Android. Very simple app with just 
> few event handlers.
> I had to use remote debugger to see console. There is resulting screenshot.
>
> Device is Samsung Galaxy S7 edge, model: SM-G935T.
> Used Go 1.11 windows/amd64.
> Simply used go build with GOOS=js and GOARCH=wasm.
>
>

-- 
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] Run time error

2018-09-18 Thread Agniva De Sarker
You have to check the Send() method on RequestBuilder and find out where 
the nil pointer is coming from.

There are no repro steps, nor the full stack trace, nor enough code for us 
to understand what is really happening. Without that it is hard to conclude 
why it is working on windows and not on ubuntu.

Your code doesn't include that library at all. And we don't know which 
request is causing the crash.

-Agniva

On Tuesday, 18 September 2018 10:22:39 UTC+5:30, akshita babel wrote:
>
> But this is code is perfectly working in windows and when i am trying to 
> run this on ubuntu it is giving the above error.
>
> On Tue, Sep 18, 2018 at 12:22 AM Justin Israel  > wrote:
>
>> Your stack trace isn't long enough to see the usage of ipfs leading up to 
>> the crash. And your example code doesn't show usage of that library. 
>> Somewhere in there you must have a nil pointer to a RequestBuilder, on 
>> which Send() is being called. 
>>
>> On Tue, Sep 18, 2018, 3:42 AM akshita babel > > wrote:
>>
>>> When I am running a program which is for a web response I am getting a 
>>> run time error as follows:
>>> http: panic serving 127.0.0.1:43802: runtime error: invalid memory 
>>> address or nil pointer dereference
>>> goroutine 6 [running]:
>>> net/http.(*conn).serve.func1(0xc4200a4a00)
>>> /usr/lib/go-1.10/src/net/http/server.go:1726 +0x11b
>>> panic(0x9b5360, 0xd99230)
>>> /usr/lib/go-1.10/src/runtime/panic.go:502 +0x24a
>>> github.com/ipfs/go-ipfs-api.(*RequestBuilder).Send(0xc4201740a0, 
>>> 0xb95c60, 0xc420022100, 0x0, 0x0, 0x0)
>>> The code of main file is as follows:
>>> func main() {
>>>
>>> router := httprouter.New()
>>> router.RedirectTrailingSlash = true
>>> c := cors.New(cors.Options{
>>> AllowedOrigins:   []string{"*"},
>>> AllowedMethods:   []string{"GET", "POST", "OPTIONS", "Authorization"},
>>> AllowedHeaders:   []string{"*"},
>>> AllowCredentials: true,
>>> })
>>> router.GET("/create", StoreAndGetHash)
>>> router.GET("/read/:hashvalue", GetFile)
>>> router.GET("/appdata/:appID", ReadPeer)
>>> router.GET("/update", UpdateAndGetHash)
>>> router.GET("/createdir", GetDir)
>>> router.GET("/newkey", GetNewKey)
>>>
>>> log.Fatal(http.ListenAndServe(":3000", c.Handler(router)))
>>>
>>> }
>>>
>>> I am working on ubuntu
>>>
>>> -- 
>>> 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...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: http client POST/GET.. will not save cookie before do redirect request

2018-09-16 Thread Agniva De Sarker


On Thursday, 13 September 2018 08:15:20 UTC+5:30, Weeds Qian wrote:
>
> If you look at my sample code, you should know I only send one request by 
> http.POST, the following request is done by golang http client automaticly, 
> not issue by myself. 
>
> You got the point , why the http client do that without cookie from last 
> response, that's what I am asking
>

The answer is already given above. You need an instance of http.Client with 
a non-nil cookie jar. Which is what I suspected in the original github 
issue. Without that, it does not capture the Set-Cookie headers.

-Agniva
 

>
> 在 2018年9月12日星期三 UTC+8下午2:52:20,Volker Dobler写道:
>>
>> On Wednesday, 12 September 2018 06:28:12 UTC+2, Weeds Qian wrote:
>>>
>>> What did you expect to see?
>>>
>>> the cookie in response
>>> What did you see instead?
>>>
>>> no cookie in response
>>>
>>>
>>> --http tcp stream from wireshark 
>>> -
>>>
>>> You can see that I only do the POST /login and the later is execute by 
>>> http client implementation.
>>>
>>> From my point of view, I think the GET /home.html request should add 
>>> the cookie from last response, but it didn't, since you don't do that, why 
>>> don't just return the response to me instead of doing useless request cause 
>>> we go the login page.
>>>
>>> POST /login HTTP/1.1
>>> Host: 127.0.0.1:8081
>>> User-Agent: Go-http-client/1.1
>>> Content-Length: 28
>>> Content-Type: application/x-www-form-urlencoded
>>> Accept-Encoding: gzip
>>>
>>> username=admin=testHTTP/1.1 302 Found
>>> Location: /home.html
>>> Set-Cookie: 
>>> user=MTUzNjY1NjA2MXxEdi1CQkFFQ180SUFBUkFCRUFBQUpfLUNBQUVHYzNSeWFXNW5EQW9BQ0hWelpYSnVZVzFsQm5OMGNtbHVad3dIQUFWaFpHMXBiZz09fKI-QQWYHP_ZywpgkIoDmTzL1eJhd7pk-i9FSUgwI89E;
>>>  Path=/; HttpOnly
>>> Date: Tue, 11 Sep 2018 08:54:21 GMT
>>> Content-Length: 0
>>>
>>>  
>> There is your cookie.
>>
>> The problem is not that the cookie is not part of the response
>> you get from /login but that you do not keep the cookie and
>> send it on subsequent requests:
>>
>>>
>>> GET /home.html HTTP/1.1
>>> Host: 127.0.0.1:8081
>>> User-Agent: Go-http-client/1.1
>>> Content-Type: application/x-www-form-urlencoded
>>> Referer: http://127.0.0.1:8081/login
>>> Accept-Encoding : gzip
>>>
>>>
>> You see: No Cookie header here.
>>
>> To record Set-Cookie headers and generate appropriate Cookie headers
>> from these set cookies you probably should use your own instance of
>> net/http.Client with a non-nil Jar and use that client to Do a POST 
>> request.
>> You can create a Jar via net/http/cookiejar.New.
>> If you are going to use this on arbitrary domains please consider setting
>> the Jar's PublicSuffixList to e.g. golang.org/x/net/publicsuffix.List
>>
>> V.
>>
>>

-- 
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: Godoc command in the future http server only?

2018-09-05 Thread Agniva De Sarker
> Any way to keep that feature when godoc is going http only in future 
releases?

Yes, that will be done.

https://github.com/golang/go/issues/25595
https://github.com/golang/go/issues/26715


On Tuesday, 4 September 2018 22:03:06 UTC+5:30, Jens-Uwe Mager wrote:
>
> I am using the godoc command to get the complete documentaion of a package 
> vs. the short form the go doc normally generates. For example the following 
> alias:
>
> alias gdf="go list ./...|fzf --preview 'go doc {}' --bind 
> 'enter:execute(godoc {}|less)'"
>
> works for me as a nice terminal go documentation browser for the current 
> go source tree I issue the command from. But this alias relies on godoc 
> delivering the complete package documentation and go doc to do the usual 
> summary. Any way to keep that feature when godoc is going http only in 
> future releases?
>
>

-- 
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: wasm_exec is no error handling.

2018-09-03 Thread Agniva De Sarker
Appears to be an oversight. Will send a CL.

On Monday, 3 September 2018 11:33:25 UTC+5:30, Kazuhiro Kubota wrote:
>
> Hi guys
>
> I found that wasm_exec.html does not handle error at Codelab in DevFest 
> tokyo 2018 ( https://tokyo2018.gdgjapan.org/ ).
> https://github.com/golang/go/blob/master/misc/wasm/wasm_exec.html#L26-L30
>
> Error handling requires .catch().
>
> I think it would be better to have error handling here.
>

-- 
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: Is the go 1.11 godoc tool 'module-aware'?

2018-08-30 Thread Agniva De Sarker
We will shift over the features from godoc to "go doc" before removing 
support, so that the output remains consistent. I think there is already an 
open issue for exactly what you have shown above. So no worries, things 
will be the same.

On Friday, 31 August 2018 02:16:54 UTC+5:30, John Shahid wrote:
>
>
> Agniva De Sarker > writes: 
>
> > Also - note that godoc cli mode is going to go away. So "godoc -links=0 
> > -html domain.com/group/project/v3/lib/foo" is not going to work after 
> 1.12. 
> > You should be using the http server. If you want command line help, use 
> "go 
> > doc". 
>
> Is there a way to get the same output as godoc ? `go doc' lists the 
> exported symbols but not their documentation.  For example the following 
> is what I get from `godoc' 
>
> func ResolveIPAddr(network, address string) (*IPAddr, error) 
> ResolveIPAddr returns an address of IP end point. 
>
> The network must be an IP network name. 
>
> If the host in the address parameter is not a literal IP address, 
> ResolveIPAddr resolves the address to an address of IP end point. 
> Otherwise, it parses the address as a literal IP address. The 
> address 
> parameter can use a host name, but this is not recommended, 
> because it 
> will return at most one of the host name's IP addresses. 
>
> See func Dial for a description of the network and address 
> parameters. 
>
>
> as opposed to the following less useful `go doc' output: 
>
> func Pipe() (Conn, Conn) 
> func ResolveIPAddr(network, address string) (*IPAddr, error) 
> func ResolveTCPAddr(network, address string) (*TCPAddr, error) 
>
> I have been relying on this behavior for a long time to open up the 
> documentation of a package and just search for the method I'm using. 
> Instead of having to open the docs for each method/symbol separately. 
>
> Thanks, 
>
> -js 
>

-- 
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: Is the go 1.11 godoc tool 'module-aware'?

2018-08-30 Thread Agniva De Sarker
Hmm .. you can still generate html docs in a round-about fashion by 
spinning up the godoc server and storing the response of the http request 
of the package path.

Otherwise, you are free to use the godoc2md tool 
- https://github.com/davecheney/godoc2md, which generates markdown pages 
from a package path. It's a great way to generate static docs.

On Friday, 31 August 2018 01:39:06 UTC+5:30, Justin Israel wrote:
>
>
>
> On Thu, Aug 30, 2018, 9:54 PM Agniva De Sarker  > wrote:
>
>> I had filed https://github.com/golang/go/issues/26827 to list the 
>> changes that godoc needs to make. Please feel free to add your comments 
>> there.
>>
>> Also - note that godoc cli mode is going to go away. So "godoc -links=0 
>> -html domain.com/group/project/v3/lib/foo" is not going to work after 
>> 1.12. You should be using the http server. If you want command line help, 
>> use "go doc".
>>
>
> Fair enough. I should just discontinue the feature we have in our build 
> systems Go tool. It was neat to generate html docs with our deploys. 
>
>
>> - Agniva
>>
>>
>> On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justin Israel wrote:
>>>
>>> Thanks for that update, Paul!
>>>
>>> On Thu, Aug 30, 2018, 2:07 AM Paul Jolly  wrote:
>>>
>>>> Perhaps better (because of the automatic linking, status updates etc)
>>>> is to create issues in respective tools under the umbrella of
>>>> https://github.com/golang/go/issues/24661
>>>>
>>>> Indeed I know there are a number of such issues, so it's just a case
>>>> of linking those from #24661.
>>>> On Wed, 29 Aug 2018 at 07:46, wilk  wrote:
>>>> >
>>>> >
>>>> > It could be fine to start a wiki page to list the tools and ide
>>>> > (not)ready for modules with the linked issues.
>>>> >
>>>> > In https://github.com/golang/go/wiki/Modules or a new page ?
>>>> >
>>>> > On 29-08-2018, Paul Jolly wrote:
>>>> > > --50127c057491b176
>>>> > > Content-Type: text/plain; charset="UTF-8"
>>>> > >
>>>> > > Please see https://github.com/golang/gddo/issues/567
>>>> > >
>>>> > > On Tue, 28 Aug 2018, 18:59 Justin Israel,  
>>>> wrote:
>>>> > >
>>>> > >> I've been trying out converting some of our internal projects to 
>>>> go 1.11
>>>> > >> using modules instead of glide. We have a build system that 
>>>> provides the
>>>> > >> ability to generate html docs via "godoc" and I am wondering if 
>>>> godoc has
>>>> > >> been made "module-aware" in go 1.11?
>>>> > >>
>>>> > >> My particular project is using the migration approach of setting 
>>>> "v3" at
>>>> > >> in the go.mod, and in all import paths within the project. But it 
>>>> seems
>>>> > >> godoc is not happy about this:
>>>> > >>
>>>> > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
>>>> > >>
>>>> > >> 2018/08/29 11:52:12 error while importing build package: cannot 
>>>> find package "domain.com/group/project/v3/lib/foo" in any of:
>>>> > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo 
>>>> (from $GOROOT)
>>>> > >> /usr/home/justin/src/go/src/
>>>> domain.com/group/project/v3/lib/foo (from $GOPATH)
>>>> > >> 2018/08/29 11:52:12 cannot find package "." in:
>>>> > >> /src/domain.com/group/project/v3/lib/foo
>>>> > >>
>>>> > >>
>>>> > >> It seems to only care about the filesystem structure and not the 
>>>> module import path naming?
>>>> > >>
>>>> > >>
>>>> > >> Justin
>>>> > >>
>>>> > >>
>>>> > >> --
>>>> > >> 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...@googlegroups.com.
>>>> > >

Re: [go-nuts] Re: Is the go 1.11 godoc tool 'module-aware'?

2018-08-30 Thread Agniva De Sarker
I had filed https://github.com/golang/go/issues/26827 to list the changes 
that godoc needs to make. Please feel free to add your comments there.

Also - note that godoc cli mode is going to go away. So "godoc -links=0 
-html domain.com/group/project/v3/lib/foo" is not going to work after 1.12. 
You should be using the http server. If you want command line help, use "go 
doc".

- Agniva


On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justin Israel wrote:
>
> Thanks for that update, Paul!
>
> On Thu, Aug 30, 2018, 2:07 AM Paul Jolly > 
> wrote:
>
>> Perhaps better (because of the automatic linking, status updates etc)
>> is to create issues in respective tools under the umbrella of
>> https://github.com/golang/go/issues/24661
>>
>> Indeed I know there are a number of such issues, so it's just a case
>> of linking those from #24661.
>> On Wed, 29 Aug 2018 at 07:46, wilk > 
>> wrote:
>> >
>> >
>> > It could be fine to start a wiki page to list the tools and ide
>> > (not)ready for modules with the linked issues.
>> >
>> > In https://github.com/golang/go/wiki/Modules or a new page ?
>> >
>> > On 29-08-2018, Paul Jolly wrote:
>> > > --50127c057491b176
>> > > Content-Type: text/plain; charset="UTF-8"
>> > >
>> > > Please see https://github.com/golang/gddo/issues/567
>> > >
>> > > On Tue, 28 Aug 2018, 18:59 Justin Israel, > > wrote:
>> > >
>> > >> I've been trying out converting some of our internal projects to go 
>> 1.11
>> > >> using modules instead of glide. We have a build system that provides 
>> the
>> > >> ability to generate html docs via "godoc" and I am wondering if 
>> godoc has
>> > >> been made "module-aware" in go 1.11?
>> > >>
>> > >> My particular project is using the migration approach of setting 
>> "v3" at
>> > >> in the go.mod, and in all import paths within the project. But it 
>> seems
>> > >> godoc is not happy about this:
>> > >>
>> > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
>> > >>
>> > >> 2018/08/29 11:52:12 error while importing build package: cannot find 
>> package "domain.com/group/project/v3/lib/foo" in any of:
>> > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo 
>> (from $GOROOT)
>> > >> /usr/home/justin/src/go/src/
>> domain.com/group/project/v3/lib/foo (from $GOPATH)
>> > >> 2018/08/29 11:52:12 cannot find package "." in:
>> > >> /src/domain.com/group/project/v3/lib/foo
>> > >>
>> > >>
>> > >> It seems to only care about the filesystem structure and not the 
>> module import path naming?
>> > >>
>> > >>
>> > >> Justin
>> > >>
>> > >>
>> > >> --
>> > >> 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...@googlegroups.com .
>> > >> For more options, visit https://groups.google.com/d/optout.
>> > >>
>> > >
>> >
>> >
>> > --
>> > William
>> >
>> > --
>> > 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...@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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Ternary ... again

2018-08-14 Thread Agniva De Sarker
Your answer is here 
- https://tip.golang.org/doc/faq#Does_Go_have_a_ternary_form.


On Tuesday, 14 August 2018 22:13:37 UTC+5:30, Mark Volkmann wrote:
>
> I’m new to Go and I imagine the idea of adding a ternary operator to Go 
> has been discussed many times. Rather than repeat that, can someone point 
> me to a discussion about why Go doesn’t add this? I’m struggling to 
> understand why it is desirable to write code like this: 
>
> var color 
> if temperature > 100 { 
> color = “red” 
> } else { 
> color = “blue” 
> } 
>
> Instead of this: 
>
> var color = temperature > 100 ? “red” : “blue” 
>
> Is the ternary really so confusing that it justifies writing 6 lines of 
> code instead of 1? I realize I could eliminate two lines like the 
> following, but this isn’t a good idea if the values come from function 
> calls since there would sometimes be needless function calls. 
>
> var color = “blue” 
> if temperature > 100 { 
> color = “red” 
> } 
>
> --- 
> R. Mark Volkmann 
> Object Computing, Inc.

-- 
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: golang + wasm three times slower than javascript?

2018-08-10 Thread Agniva De Sarker
>  however I expected at least equal to or better performance than JS.

Hi,

Unfortunately, this expectation is incorrect. Wasm is NOT guaranteed to 
give you better or at least equal performance to javascript. This is even 
in the general case when you run wasm using emcc. The performance is very 
dependant on what you are running and on which browser (sometimes even 
browser versions matter). 

Take a look at this to see how does the performance vary 
- https://takahirox.github.io/WebAssembly-benchmark/.

Coming to Go, 1.11 will just have experimental support. We are just 
focusing on correctness as of now. Also, there are couple of issues in the 
wasm spec itself which impediments a language like Go which needs to unwind 
and restore the call stack when switching between goroutines. This is only 
related to Go though. But even in the general case, wasm performance is not 
always better than javascript. WebAssembly is not a silver bullet.

-Agniva

On Friday, 10 August 2018 15:58:01 UTC+5:30, netbrain wrote:
>
> So been playing around with go and wasm support on go version devel 
> +479da24aac Fri Aug 10 00:47:31 2018 + linux/amd64
>
> Curious on performance i tried implementing a Fibonacci algorithm function 
> in JS and compared it to it's equivalent in GO. Calculating fib(44) takes 
> 11 seconds on my machine in JS and in GO it takes 36 seconds.
>
> Any idea's to why I would get these results? I know wasm is very much an 
> experimental feature of go, however I expected at least equal to or better 
> performance than JS. Are there any browser optimizations which is running 
> in my JS code which may not be in effect in wasm?
>
> Test code available at 
> https://github.com/netbrain/kata/tree/master/go/wasm
>
> Cheers
> Kim
>

-- 
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] [Question]: Are there any plans to teach the compiler to emit VEX encoded instructions ?

2018-03-01 Thread Agniva De Sarker
Oops, spoke too soon. Got you now Ian. Thanks.

On Mar 2, 2018 1:37 AM, "Agniva De Sarker" <agniva.quicksil...@gmail.com>
wrote:

> We can still support all processors. I believe it should be possible to
> check for cpuid flags and conditionally emit these instructions.
>
> On Mar 2, 2018 12:23 AM, "Ian Lance Taylor" <i...@golang.org> wrote:
>
>> On Thu, Mar 1, 2018 at 5:05 AM, Agniva De Sarker
>> <agniva.quicksil...@gmail.com> wrote:
>> >
>> > I believe using the non-destructive 3 operand form will help a lot in
>> > reducing the size of binaries. And also, it might give us a good base
>> to add
>> > FMA support and SIMD optimizations later.
>> >
>> > I have been adding fast paths to some math functions to use AVX
>> > instructions, but I was just wondering if there is any plan in the
>> pipeline
>> > to do this from the compiler itself.
>>
>> We would have to make a clear decision as to the oldest amd64
>> processor we wanted to support.  Right now I believe we support all
>> amd64 processors.  Are we ready to give up on old ones?
>>
>> I don't think it's worth adding a GOAMD64 environment variable for
>> this.  I don't think the gain is worth the complexity.  Happy to be
>> proven wrong.
>>
>> 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.


Re: [go-nuts] [Question]: Are there any plans to teach the compiler to emit VEX encoded instructions ?

2018-03-01 Thread Agniva De Sarker
We can still support all processors. I believe it should be possible to
check for cpuid flags and conditionally emit these instructions.

On Mar 2, 2018 12:23 AM, "Ian Lance Taylor" <i...@golang.org> wrote:

> On Thu, Mar 1, 2018 at 5:05 AM, Agniva De Sarker
> <agniva.quicksil...@gmail.com> wrote:
> >
> > I believe using the non-destructive 3 operand form will help a lot in
> > reducing the size of binaries. And also, it might give us a good base to
> add
> > FMA support and SIMD optimizations later.
> >
> > I have been adding fast paths to some math functions to use AVX
> > instructions, but I was just wondering if there is any plan in the
> pipeline
> > to do this from the compiler itself.
>
> We would have to make a clear decision as to the oldest amd64
> processor we wanted to support.  Right now I believe we support all
> amd64 processors.  Are we ready to give up on old ones?
>
> I don't think it's worth adding a GOAMD64 environment variable for
> this.  I don't think the gain is worth the complexity.  Happy to be
> proven wrong.
>
> 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] [Question]: Are there any plans to teach the compiler to emit VEX encoded instructions ?

2018-03-01 Thread Agniva De Sarker
Hi,

I believe using the non-destructive 3 operand form will help a lot in 
reducing the size of binaries. And also, it might give us a good base to 
add FMA support and SIMD optimizations later.

I have been adding fast paths to some math functions to use AVX 
instructions, but I was just wondering if there is any plan in the pipeline 
to do this from the compiler itself.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Extensive Go resources for CS101

2018-02-03 Thread Agniva De Sarker
Really nice to hear universities taking up Go ! I hope the day comes when 
we don't have to learn programming by learning C anymore. 



On Saturday, 3 February 2018 16:00:20 UTC+5:30, Henrik Johansson wrote:
>
> This is good news in so many ways! Finally a useable language in 
> university courses! Sure everyone could use a good lisp now and then but 
> for most engineering getting to useable stuff fast is very important.
>
> And there is a lot of stuff there! Thank you!
>
> lör 3 feb. 2018 kl 11:18 skrev Stefan Nilsson  >:
>
>> At KTH in Stockholm we’ve been using Go to teach the basics of concurrent 
>> programming for a few years, and we might go ahead and use Go for Computer 
>> Science 101 as well. Preparing for this, I’ve put together a fairly 
>> extensive set of articles, cheat sheets and how to’s at
>>
>> http://yourbasic.org/golang/
>>
>> It’s freely available under a CC license, and I hope it can be of use to 
>> some of you as well.
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Re: Interest in implementing dual-pivot or 3-pivot quicksort for faster sorting?

2017-11-22 Thread Agniva De Sarker
This definitely sounds interesting. Will be glad to help out.



On Wednesday, 22 November 2017 23:33:18 UTC+5:30, David McManamon wrote:
>
> Sometimes it takes years for great technical papers to be implemented.  As 
> a fun exercise to compare Java's dual-pivot (since so much work went into 
> it) with the 3-pivot described in the paper:
> Multi-Pivot Quicksort: Theory and Experiments 
> downloaded from:
> http://epubs.siam.org/doi/pdf/10.1137/1.9781611973198.6 
> I wrote the 3-pivot quicksort described in the paper and for sorting 10 
> million elements it was about 10% faster than Arrays.sort() and completes 
> in 1 second on my 2013 computer.
> Feel free to run the code if you have any doubts:
>
> https://github.com/dmcmanam/quicksort/tree/master/src
>
> And I wrote a quick blog post for background which also explains why I'm 
> looking for languages like Go to implement this in:
>
>
> https://refactoringlightly.wordpress.com/2017/11/21/multi-pivot-quicksort-aka-3-pivot-quicksort/
>
> Any interest in working with me to write a Go version?  Some discussion & 
> pair programming would be fun since so far I have only written 1 go 
> algorithm - AVL trees since I was surprised to see people using LLRB in Go 
> but I was guessing there is less interest in better balanced binary search 
> trees.  The project would have a few steps, working on benchmarks for edge 
> cases, etc.  
>
> --David
>

-- 
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: Getting some strange benchmark results

2017-08-18 Thread Agniva De Sarker
Thanks


On Aug 18, 2017 1:42 PM,  wrote:

> From the recent GopherCon, golang's profiler has a tool for inspecting
> allocations that might solve your problem.
>
> https://youtu.be/2557w0qsDV0?list=PLq2Nv-Sh8EbZEjZdPLaQt1qh_ohZFMDj8=526
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/0vTMTgwmv4E/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Getting some strange benchmark results

2017-08-17 Thread Agniva De Sarker

Hi everyone,

I have a piece of code which is behaving a bit strangely in benchmarks. 
Here is a simplified version of it.

The only difference is that in one case, the destination is a different 
slice. On the other case, its the same slice as source.


func BenchmarkStringCreate(b *testing.B) {
for n := 0; n < b.N; n++ {
DecodeStringCreate("ab")
}
}

func BenchmarkStringNoCreate(b *testing.B) {
for n := 0; n < b.N; n++ {
DecodeStringNoCreate("ab")
}
}

func DecodeStringCreate(str string) []byte {
dst := make([]byte, 2)
src := []byte(str)
Decode(dst, src)
return dst
}

func DecodeStringNoCreate(str string) []byte {
src := []byte(str)
Decode(src, src)
return src
}

func Decode(dst, src []byte) {
for i := 0; i < 1; i++ {
dst[0] = src[0]
}
}



BenchmarkStringCreate-4 500037.2 ns/op   2 
B/op   1 allocs/op
BenchmarkStringNoCreate-4   300044.3 ns/op   8 
B/op   1 allocs/op
PASS
ok  stdtest3.279s

It seems very strange to me that on the case where I am not allocating any 
slice, allocates 8 bytes of memory, whereas, when I create the slice of 2, 
it clearly allocates only 2 bytes.

Now here is the fun part, if I change the Decode function to remove the for 
loop, all allocations go down to zero.

func Decode(dst, src []byte) {
  dst[0] = src[0]
}


BenchmarkStringCreate-4 1 10.2 ns/op 0 B/op 0 allocs/op
BenchmarkStringNoCreate-4 2 9.85 ns/op 0 B/op 0 allocs/op
PASS
ok stdtest 4.000s

How come removing the for loop changes the no. of allocations ? And the 
loop always runs only 1 iteration anyway. I have no clue as to what is 
happening here. 

Any help will be appreciated. Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Cast from int to uint64 performance cost

2016-10-01 Thread Agniva De Sarker
Thanks ! Appreciate the help. :)

On Saturday, 1 October 2016 22:16:10 UTC+5:30, Ian Lance Taylor wrote:
>
> On Sat, Oct 1, 2016 at 12:24 AM,   
> wrote: 
> > 
> > I am using a variable to track the no. of bytes written to a file so 
> far. 
> > Now the fmt.Fprint command returns the bytes written as int. But I am 
> > thinking of storing the value as a uint64 just to give it some extra 
> space. 
> > Therefore, I have to do a bytesWritten += uint64(n) to add to the 
> variable. 
> > 
> > This code is in the hot path of my application. I was just wondering 
> what is 
> > the performance hit of the casting and whether there is any better way 
> to 
> > achieve this ? 
>
> Converting from int to uint64 is very cheap.  In fact, on many 
> processors, the performance cost is exactly zero.  Don't worry about 
> it. 
>
> 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.