Re: [go-nuts] Re: Fancy Comments & Documentation

[Rob Pike]

If you want gofmt to preserve ASCII art, just indent it.

https://play.golang.org/p/2ulwl8orRlG

On Fri, Apr 20, 2018 at 3:47 PM, Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> If your variable and function names don't explain what is going on, you
> will encounter a big maintenance problem with your code as non-updated
> comments contradict your unreadable code.
>
> Very occasionally I find a use for attention-grabbing comments, number one
> for this, and personally I consider this to be a flaw in the design of Go's
> type struct and interface{} syntax is to isolate unimplemented code in
> superclasses. In my code I use somewhat space-consuming commentary to show
> the head and tail of the section that contains all the skeleton functions
> required to allow parametric polymorphism and composition/inheritance. I
> think it is a good case to argue that type struct should have three
> sections, first, the struct variable elements, second for the template
> function signatures, and third for the implementations. Well, I would even
> suggest it should have a section for 'dummy' functions. Or maybe some
> indicator in the interface that means the code will not run without a
> composition overlaid to implement these functions.
>
> It's not a dealbreaker for me, but I don't think the flexibility, while
> there is a syntactic constraint that there must be a function declaration
> for any function called, that requires what amounts to dumb boilerplate,
> will remain in the Go spec down the track.
>
> On Friday, 20 April 2018 03:18:40 UTC+3, matthe...@gmail.com wrote:
>>
>> gofmt and godoc remove choices that are fun, artistic, or tempting, but
>> distracting. I think you'll be best served by Go without the box.
>>
>> Matt
>>
>> On Thursday, April 19, 2018 at 6:42:40 PM UTC-5, Chris FractalBach wrote:
>>>
>>> Test #1
>>> Source:
>>> /*
>>> +--+
>>> |   fancy box  |
>>> +--+
>>> package goexplore explores Go!
>>> */
>>> package goexplore
>>>
>>> Result:
>>>
>>>
>>> 
>>>
>>>
>>>
>>> Test #2
>>> Source:
>>> /*
>>> +--+
>>> |   fancy box  |
>>> +--+
>>> */
>>>
>>> /*
>>> package goexplore explores Go!
>>> */
>>> package goexplore
>>>
>>>
>>> Result:
>>>
>>>
>>> 
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: Fancy Comments & Documentation

[Louki Sumirniy]

If your variable and function names don't explain what is going on, you 
will encounter a big maintenance problem with your code as non-updated 
comments contradict your unreadable code.

Very occasionally I find a use for attention-grabbing comments, number one 
for this, and personally I consider this to be a flaw in the design of Go's 
type struct and interface{} syntax is to isolate unimplemented code in 
superclasses. In my code I use somewhat space-consuming commentary to show 
the head and tail of the section that contains all the skeleton functions 
required to allow parametric polymorphism and composition/inheritance. I 
think it is a good case to argue that type struct should have three 
sections, first, the struct variable elements, second for the template 
function signatures, and third for the implementations. Well, I would even 
suggest it should have a section for 'dummy' functions. Or maybe some 
indicator in the interface that means the code will not run without a 
composition overlaid to implement these functions.

It's not a dealbreaker for me, but I don't think the flexibility, while 
there is a syntactic constraint that there must be a function declaration 
for any function called, that requires what amounts to dumb boilerplate, 
will remain in the Go spec down the track.

On Friday, 20 April 2018 03:18:40 UTC+3, matthe...@gmail.com wrote:
>
> gofmt and godoc remove choices that are fun, artistic, or tempting, but 
> distracting. I think you'll be best served by Go without the box.
>
> Matt
>
> On Thursday, April 19, 2018 at 6:42:40 PM UTC-5, Chris FractalBach wrote:
>>
>> Test #1
>> Source:
>> /*
>> +--+
>> |   fancy box  |
>> +--+
>> package goexplore explores Go!
>> */
>> package goexplore
>>
>> Result:
>>
>>
>> 
>>
>>
>>
>> Test #2
>> Source:
>> /*
>> +--+
>> |   fancy box  |
>> +--+
>> */
>>
>> /*
>> package goexplore explores Go!
>> */
>> package goexplore
>>
>>
>> Result:
>>
>>
>> 
>>
>>

-- 
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] Go-path from a source other than $GOPATH (and package management)

[Kaveh Shahbazian]

BTW I was wrong about multiple go-paths. During implementation, I've learnt 
lots of import path overwriting must take place to handle nested 
dependencies of different versions, properly.

Well then, waiting for vgo.

-- 
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 "alt" attribute value for img tag?

[Timothy Raymond]

You should have a look at http://go-colly.org . I've done scraping with 
html.Parse before, and I wish Colly existed when I did.

-- 
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: Fancy Comments & Documentation

[matthewjuran]

gofmt and godoc remove choices that are fun, artistic, or tempting, but 
distracting. I think you'll be best served by Go without the box.

Matt

On Thursday, April 19, 2018 at 6:42:40 PM UTC-5, Chris FractalBach wrote:
>
> Test #1
> Source:
> /*
> +--+
> |   fancy box  |
> +--+
> package goexplore explores Go!
> */
> package goexplore
>
> Result:
>
>
> 
>
>
>
> Test #2
> Source:
> /*
> +--+
> |   fancy box  |
> +--+
> */
>
> /*
> package goexplore explores Go!
> */
> package goexplore
>
>
> Result:
>
>
> 
>
>

-- 
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: Fancy Comments & Documentation

[Chris FractalBach]

Test #1
Source:
/*
+--+
|   fancy box  |
+--+
package goexplore explores Go!
*/
package goexplore

Result:





Test #2
Source:
/*
+--+
|   fancy box  |
+--+
*/

/*
package goexplore explores Go!
*/
package goexplore


Result:



-- 
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] using ginkgo

[Keith Brown]

I would like to have a tool for testing infrastructure components. I 
stumbled across Ginkgo. Does anyone use it?  Does it need a go compiler for 
tests? My intention is to write simple tests, "Is server up?". "Does the 
file contain abc". But I don't want to have the go compiler installed to 
run the library. Does such a tool exist?


-- 
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] Go-path from a source other than $GOPATH (and package management)

[Kaveh Shahbazian]

You are right. That is very similar except that, instead of having a 
convention for naming directories, there should exist a .goenv in the 
working directory (or a up parent). In this .goenv file a go-path can be 
set - and maybe other go env vars.

This way, it is possible to take advantage of having multiple paths in a 
$GOPATH (-like) env var. The go tools will work with the first one. They 
also look into the second path or other paths after that, if a package can 
not be found inside the first path.

In short, the base idea is being able to set the first path in a list of 
paths (inside the $GOPATH var), in a project-specific way. And it is 
exactly how go tools use $GOPATH currently.

The only difference is there should be another way to introduce go-path to 
go tools, other than $GOPATH env var.

On Thursday, April 19, 2018 at 5:28:39 PM UTC+4:30, Paul Jolly wrote:
>
> I think you're getting at something similar to:
>
>
> https://docs.google.com/document/d/1Ee8POHVeo3N6c1pgiubdWoUJoYkD5cwY3p8rqonRY0o/edit
>
> Implemented roughly here:
>
> https://github.com/myitcv/go
>
> This was itself similar to/influenced by:
>
> https://github.com/golang/go/issues/17271#issuecomment-268301191
>
> In any case I think all of this becomes irrelevant in the context of vgo: 
>
> https://research.swtch.com/vgo
>
> On 19 April 2018 at 13:48, Kaveh Shahbazian  > wrote:
>
>> Is it possible to tell go tools to get the go-path from a source other 
>> than $GOPATH?
>>
>> Notes:
>>
>> Assuming the answer is no, I wish it was possible.
>>
>> For example when running a go command from the current directory, it go 
>> search the current directory, or goes up, until it finds a (for example) 
>> *.goenv* file, in which the GOPATH for current directory is specified.
>>
>> And the system-wide $GOPATH would act as a fall-back option, an umbrella 
>> root.
>>
>> This way the current project can have all of its stuff under the 
>> directory that contains the specified .goenv without interfering with other 
>> packages.
>>
>> Now if the current package (A) has two dependencies B and C and B uses a 
>> different version of C, then B can simply resides in a parallel directory 
>> to the current directory and be found in the system-wide $GOPATH.
>>
>> But go tools would always look for .goenv first.
>>
>> Seems to occupy the same amount of disk space as any other way of 
>> managing packages.
>>
>> -- 
>> 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] binary tree. different results on linux 64 and windows 32 machines.

[Alex Dvoretskiy]

Thanks a lot!!!

On Thursday, April 19, 2018 at 11:55:49 AM UTC-7, Bakul Shah wrote:
>
> Terminate Scanf format strings with \n. To see why, do "go doc fmt.Scanf". 
> Always check the result of (at least) any input operation such as Scanf.
>
> On Apr 19, 2018, at 10:31 AM, Alex Dvoretskiy  > wrote:
>
> Hello Golang-nuts,
>
> Following code reads data from file and creates binary tree structure:
>
> '
> // go run main.go < input
>
> package main
>
> import "fmt"
>
> type TreeNode struct {
> Value int
> Left *TreeNode
> Right *TreeNode
> }
>
> func main () {
> nodes := read()
>
> for i, node := range(nodes) {
> fmt.Printf("%p\n", [i])
> printNode()
> }
>
> //passing root node
> fmt.Println(nodes)
> fmt.Println(maxDepth([len(nodes) - 1]))
> }
>
> func maxDepth(root *TreeNode) int {
> if root == nil {
> return 0
> }
> dl := 1 + maxDepth(root.Left)
> dr := 1 + maxDepth(root.Right)
> if dl > dr {
> return dl
> } else {
> return dr
> }
> }
>
> func read() []TreeNode {
> /*test := {
> 1,
> nil,
> nil,
> }
> right := {
> 33,
> nil,
> nil,
> }
> test.Right = right
> fmt.Println(test)
> printNode(test)*/
>
> var N int
> fmt.Scanf("%d", )
> fmt.Println("N: ", N)
>
> var nodes []TreeNode = make([]TreeNode, N)
>
> var val, indexLeft, indexRight int
> for i := 0; i < N; i++ {
> fmt.Scanf("%d %d %d", , , )
> nodes[i].Value = val
> if indexLeft >= 0 {
> nodes[i].Left = [indexLeft]
> }
> if indexRight >= 0 {
> nodes[i].Right = [indexRight]
> }
> }
>
> return nodes
> }
>
> func printNode(n *TreeNode) {
> fmt.Print("Value: ", n.Value)
> if n.Left != nil {
> fmt.Print(" Left: ", n.Left.Value)
> }
> if n.Right != nil {
> fmt.Print(" Right: ", n.Right.Value)
> }
> fmt.Println()
> }
> '
> Code works fine on Linux64 machine, result: "[{15  } {7  
> } {9  } {20 0x11958080 0x1195808c} {3 0x11958098 
> 0x119580a4}]"
> maxDepth = 3
>
> But if, I'm runing this code on windows 32 machine, I'm getting different 
> result: "[{0 0x11a94000 0x11a94000} {15  } {15  } {7 
>  } {7  }]"
> maxDepth = 1
> which is not correct.
>
> Go version 10.0. Windows Server Standard 2007 SP2 2007.
> What is wrong? Is it a bug? Or something wrong with my code? 
>
>
> This is something to do with fmt.Scanf
>
> When I don't read data from file using fmt.Scanf the code works fine on 
> both machines:
> https://play.golang.org/p/Rhi5jJKGYjX
>
> Please advise.
>
> -- 
> 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] binary tree. different results on linux 64 and windows 32 machines.

[Bakul Shah]

Terminate Scanf format strings with \n. To see why, do "go doc fmt.Scanf". 
Always check the result of (at least) any input operation such as Scanf.

> On Apr 19, 2018, at 10:31 AM, Alex Dvoretskiy  wrote:
> 
> Hello Golang-nuts,
> 
> Following code reads data from file and creates binary tree structure:
> 
> '
> // go run main.go < input
> 
> package main
> 
> import "fmt"
> 
> type TreeNode struct {
>   Value int
>   Left *TreeNode
>   Right *TreeNode
> }
> 
> func main () {
>   nodes := read()
> 
>   for i, node := range(nodes) {
>   fmt.Printf("%p\n", [i])
>   printNode()
>   }
> 
>   //passing root node
>   fmt.Println(nodes)
>   fmt.Println(maxDepth([len(nodes) - 1]))
> }
> 
> func maxDepth(root *TreeNode) int {
>   if root == nil {
>   return 0
>   }
>   dl := 1 + maxDepth(root.Left)
>   dr := 1 + maxDepth(root.Right)
>   if dl > dr {
>   return dl
>   } else {
>   return dr
>   }
> }
> 
> func read() []TreeNode {
>   /*test := {
>   1,
>   nil,
>   nil,
>   }
>   right := {
>   33,
>   nil,
>   nil,
>   }
>   test.Right = right
>   fmt.Println(test)
>   printNode(test)*/
> 
>   var N int
>   fmt.Scanf("%d", )
>   fmt.Println("N: ", N)
> 
>   var nodes []TreeNode = make([]TreeNode, N)
> 
>   var val, indexLeft, indexRight int
>   for i := 0; i < N; i++ {
>   fmt.Scanf("%d %d %d", , , )
>   nodes[i].Value = val
>   if indexLeft >= 0 {
>   nodes[i].Left = [indexLeft]
>   }
>   if indexRight >= 0 {
>   nodes[i].Right = [indexRight]
>   }
>   }
> 
>   return nodes
> }
> 
> func printNode(n *TreeNode) {
>   fmt.Print("Value: ", n.Value)
>   if n.Left != nil {
>   fmt.Print(" Left: ", n.Left.Value)
>   }
>   if n.Right != nil {
>   fmt.Print(" Right: ", n.Right.Value)
>   }
>   fmt.Println()
> }
> '
> Code works fine on Linux64 machine, result: "[{15  } {7  
> } {9  } {20 0x11958080 0x1195808c} {3 0x11958098 0x119580a4}]"
> maxDepth = 3
> 
> But if, I'm runing this code on windows 32 machine, I'm getting different 
> result: "[{0 0x11a94000 0x11a94000} {15  } {15  } {7 
>  } {7  }]"
> maxDepth = 1
> which is not correct.
> 
> Go version 10.0. Windows Server Standard 2007 SP2 2007.
> What is wrong? Is it a bug? Or something wrong with my code? 
> 
> 
> This is something to do with fmt.Scanf
> 
> When I don't read data from file using fmt.Scanf the code works fine on both 
> machines:
> https://play.golang.org/p/Rhi5jJKGYjX
> 
> Please advise.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Re: binary tree. different results on linux 64 and windows 32 machines.

[Alex Dvoretskiy]

Added files. Semicolon made no difference. Still wrong result on win32.

On Thursday, April 19, 2018 at 10:45:35 AM UTC-7, Louki Sumirniy wrote:
>
> You need to show the input file also. I can only guess this has something 
> to do with maybe cr/lf? What happens if you add a distinct separator to the 
> input such as a semicolon?
>
> On Thursday, 19 April 2018 20:31:56 UTC+3, Alex Dvoretskiy wrote:
>>
>> Hello Golang-nuts,
>>
>> Following code reads data from file and creates binary tree structure:
>>
>> '
>> // go run main.go < input
>>
>> package main
>>
>> import "fmt"
>>
>> type TreeNode struct {
>> Value int
>> Left *TreeNode
>> Right *TreeNode
>> }
>>
>> func main () {
>> nodes := read()
>>
>> for i, node := range(nodes) {
>> fmt.Printf("%p\n", [i])
>> printNode()
>> }
>>
>> //passing root node
>> fmt.Println(nodes)
>> fmt.Println(maxDepth([len(nodes) - 1]))
>> }
>>
>> func maxDepth(root *TreeNode) int {
>> if root == nil {
>> return 0
>> }
>> dl := 1 + maxDepth(root.Left)
>> dr := 1 + maxDepth(root.Right)
>> if dl > dr {
>> return dl
>> } else {
>> return dr
>> }
>> }
>>
>> func read() []TreeNode {
>> /*test := {
>> 1,
>> nil,
>> nil,
>> }
>> right := {
>> 33,
>> nil,
>> nil,
>> }
>> test.Right = right
>> fmt.Println(test)
>> printNode(test)*/
>>
>> var N int
>> fmt.Scanf("%d", )
>> fmt.Println("N: ", N)
>>
>> var nodes []TreeNode = make([]TreeNode, N)
>>
>> var val, indexLeft, indexRight int
>> for i := 0; i < N; i++ {
>> fmt.Scanf("%d %d %d", , , )
>> nodes[i].Value = val
>> if indexLeft >= 0 {
>> nodes[i].Left = [indexLeft]
>> }
>> if indexRight >= 0 {
>> nodes[i].Right = [indexRight]
>> }
>> }
>>
>> return nodes
>> }
>>
>> func printNode(n *TreeNode) {
>> fmt.Print("Value: ", n.Value)
>> if n.Left != nil {
>> fmt.Print(" Left: ", n.Left.Value)
>> }
>> if n.Right != nil {
>> fmt.Print(" Right: ", n.Right.Value)
>> }
>> fmt.Println()
>> }
>> '
>> Code works fine on Linux64 machine, result: "[{15  } {7  
>> } {9  } {20 0x11958080 0x1195808c} {3 0x11958098 
>> 0x119580a4}]"
>> maxDepth = 3
>>
>> But if, I'm runing this code on windows 32 machine, I'm getting different 
>> result: "[{0 0x11a94000 0x11a94000} {15  } {15  } {7 
>>  } {7  }]"
>> maxDepth = 1
>> which is not correct.
>>
>> Go version 10.0. Windows Server Standard 2007 SP2 2007.
>> What is wrong? Is it a bug? Or something wrong with my code? 
>>
>>
>> This is something to do with fmt.Scanf
>>
>> When I don't read data from file using fmt.Scanf the code works fine on 
>> both machines:
>> https://play.golang.org/p/Rhi5jJKGYjX
>>
>> Please advise.
>>
>

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


input
Description: Binary data


main.go
Description: Binary data

[go-nuts] Re: binary tree. different results on linux 64 and windows 32 machines.

[Louki Sumirniy]

You need to show the input file also. I can only guess this has something 
to do with maybe cr/lf? What happens if you add a distinct separator to the 
input such as a semicolon?

On Thursday, 19 April 2018 20:31:56 UTC+3, Alex Dvoretskiy wrote:
>
> Hello Golang-nuts,
>
> Following code reads data from file and creates binary tree structure:
>
> '
> // go run main.go < input
>
> package main
>
> import "fmt"
>
> type TreeNode struct {
> Value int
> Left *TreeNode
> Right *TreeNode
> }
>
> func main () {
> nodes := read()
>
> for i, node := range(nodes) {
> fmt.Printf("%p\n", [i])
> printNode()
> }
>
> //passing root node
> fmt.Println(nodes)
> fmt.Println(maxDepth([len(nodes) - 1]))
> }
>
> func maxDepth(root *TreeNode) int {
> if root == nil {
> return 0
> }
> dl := 1 + maxDepth(root.Left)
> dr := 1 + maxDepth(root.Right)
> if dl > dr {
> return dl
> } else {
> return dr
> }
> }
>
> func read() []TreeNode {
> /*test := {
> 1,
> nil,
> nil,
> }
> right := {
> 33,
> nil,
> nil,
> }
> test.Right = right
> fmt.Println(test)
> printNode(test)*/
>
> var N int
> fmt.Scanf("%d", )
> fmt.Println("N: ", N)
>
> var nodes []TreeNode = make([]TreeNode, N)
>
> var val, indexLeft, indexRight int
> for i := 0; i < N; i++ {
> fmt.Scanf("%d %d %d", , , )
> nodes[i].Value = val
> if indexLeft >= 0 {
> nodes[i].Left = [indexLeft]
> }
> if indexRight >= 0 {
> nodes[i].Right = [indexRight]
> }
> }
>
> return nodes
> }
>
> func printNode(n *TreeNode) {
> fmt.Print("Value: ", n.Value)
> if n.Left != nil {
> fmt.Print(" Left: ", n.Left.Value)
> }
> if n.Right != nil {
> fmt.Print(" Right: ", n.Right.Value)
> }
> fmt.Println()
> }
> '
> Code works fine on Linux64 machine, result: "[{15  } {7  
> } {9  } {20 0x11958080 0x1195808c} {3 0x11958098 
> 0x119580a4}]"
> maxDepth = 3
>
> But if, I'm runing this code on windows 32 machine, I'm getting different 
> result: "[{0 0x11a94000 0x11a94000} {15  } {15  } {7 
>  } {7  }]"
> maxDepth = 1
> which is not correct.
>
> Go version 10.0. Windows Server Standard 2007 SP2 2007.
> What is wrong? Is it a bug? Or something wrong with my code? 
>
>
> This is something to do with fmt.Scanf
>
> When I don't read data from file using fmt.Scanf the code works fine on 
> both machines:
> https://play.golang.org/p/Rhi5jJKGYjX
>
> Please advise.
>

-- 
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] binary tree. different results on linux 64 and windows 32 machines.

[Alex Dvoretskiy]

Hello Golang-nuts,

Following code reads data from file and creates binary tree structure:

'
// go run main.go < input

package main

import "fmt"

type TreeNode struct {
Value int
Left *TreeNode
Right *TreeNode
}

func main () {
nodes := read()

for i, node := range(nodes) {
fmt.Printf("%p\n", [i])
printNode()
}

//passing root node
fmt.Println(nodes)
fmt.Println(maxDepth([len(nodes) - 1]))
}

func maxDepth(root *TreeNode) int {
if root == nil {
return 0
}
dl := 1 + maxDepth(root.Left)
dr := 1 + maxDepth(root.Right)
if dl > dr {
return dl
} else {
return dr
}
}

func read() []TreeNode {
/*test := {
1,
nil,
nil,
}
right := {
33,
nil,
nil,
}
test.Right = right
fmt.Println(test)
printNode(test)*/

var N int
fmt.Scanf("%d", )
fmt.Println("N: ", N)

var nodes []TreeNode = make([]TreeNode, N)

var val, indexLeft, indexRight int
for i := 0; i < N; i++ {
fmt.Scanf("%d %d %d", , , )
nodes[i].Value = val
if indexLeft >= 0 {
nodes[i].Left = [indexLeft]
}
if indexRight >= 0 {
nodes[i].Right = [indexRight]
}
}

return nodes
}

func printNode(n *TreeNode) {
fmt.Print("Value: ", n.Value)
if n.Left != nil {
fmt.Print(" Left: ", n.Left.Value)
}
if n.Right != nil {
fmt.Print(" Right: ", n.Right.Value)
}
fmt.Println()
}
'
Code works fine on Linux64 machine, result: "[{15  } {7  
} {9  } {20 0x11958080 0x1195808c} {3 0x11958098 
0x119580a4}]"
maxDepth = 3

But if, I'm runing this code on windows 32 machine, I'm getting different 
result: "[{0 0x11a94000 0x11a94000} {15  } {15  } {7 
 } {7  }]"
maxDepth = 1
which is not correct.

Go version 10.0. Windows Server Standard 2007 SP2 2007.
What is wrong? Is it a bug? Or something wrong with my code? 


This is something to do with fmt.Scanf

When I don't read data from file using fmt.Scanf the code works fine on 
both machines:
https://play.golang.org/p/Rhi5jJKGYjX

Please advise.

-- 
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] Extension for type assertion of interface array

[jake6502]

Yes, to use the functions above you will need to copy the slices of 
landSpaceto slices of the respective interface types. But I you do not need 
to do any type assertions. Like this: 

https://play.golang.org/p/eFTUqpImyPc
package main

import (
"fmt"
)

type landSpace struct{}

func (*landSpace) Foo() {
fmt.Println("Foo")
}

func (*landSpace) Bar() {
fmt.Println("Bar")
}

type Shape interface {
Foo()
}

type Property interface {
Bar()
}

var a []*landSpace

func processShapes(shapes []Shape) {
for _, s := range shapes {
s.Foo()
}
}

func evaluateProperties(properties []Property) {
for _, p := range properties {
p.Bar()
}
}

func main() {
a = append(a, {}, {})

var shapes []Shape
for _, l := range a {
shapes = append(shapes, l)
}
processShapes(shapes)

var properties []Property
for _, l := range a {
properties = append(properties, l)
}
evaluateProperties(properties)
fmt.Println("Hello, playground")
}

Is this what you meant? I see how something like shapes = a.([]Shape) would 
be convenient to avoid having to do an explicit conversion. Hoever, until 
Go has some form of generics,  it seems unlikely. Keep in mind that a Shape and 
*landSpace are two different types, with different in memory 
representations. So to avoid major language changes, the type assertion 
would have to create a new slice anyway.


On Thursday, April 19, 2018 at 12:59:12 AM UTC-4, Sakthi Natesan wrote:
>
> Usescases that I came across doesn't involve []interface{}. 
>
> My usecases will be similar to this sample code 
> 
>
> type landSpace struct {
> //consider that landSpace implements all functions from both Shape and 
> property interfaces
> ...
> }
> type Shape interface {
> ...
> }
>
>
> type property interface {
>
> ...
> }
>
>
> var a []*landSpace
>
> func processShapes(shapes []Shape) {
> //
> }
>
> func evaluateProperties(properties []Property) {
> //
> }
>
>
>
> If I want to pass the variable 'a' to both the functions, then I have to 
> write two functions to clone and typeAssert to respective interfaces.
>
>
> On Wednesday, 18 April 2018 19:53:33 UTC+5:30, Jan Mercl wrote:
>>
>> On Wed, Apr 18, 2018 at 4:13 PM  wrote:
>>
>> When possible, avoid using '[]interface{}' and use just 'interface{}' 
>> instead: https://play.golang.org/p/oPtPoGChkMZ.
>>
>>
>> -- 
>>
>> -j
>>
>

-- 
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: rest apis in golang accepting a file upload and another API to stream the file content

[rugwirobaker]

Actually I have almost the same scenario: I am trying to upload large files 
as a stream. Do you think the io.Copy() method would work for me? If not 
what do you recommend.

On Friday, 27 November 2015 04:15:16 UTC+2, suman jakkula wrote:
>
> Is there any example of uploading a file to Rest API (POST) implemented 
> using Gorilla library in Go? This API should be accessible via curl, chrome 
> Rest client or any other http rest clients.
> Examples I googled show uploading from a web page Form.
>

-- 
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: Why not tuples?

[Louki Sumirniy]

Multiple return values. They do kinda exist in a declarative form of sorts, 
in the type signature, this sets the number and sequence and types of 
return values. You could even make functions accept them as also input 
values, I think, but I don't think it works exactly like this. I'm not a 
fan of these things because of how you have to nominate variables or _ and 
type inference will make these new variables, if you  := into whatever the 
return was.

I'm not sure what the correct word is for them. Untyped in the same way 
that literals can be multiple types (especially integers) but singular in 
their literal form.

On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy  > wrote:
>
> > Sorry for the self-promotion but it was relevant in that I was working 
> on how to tidy up the readability of my code and needed multiple returns 
> and simple untyped tuples were really not nearly as convenient as using a 
> type struct.
>
> I have no idea what you mean by 'untyped tuples' because Go does not have 
> tuples, or at least not as a well defined thing. I can only guess if you're 
> trying to implement tuples in Go with an array, slice or a struct, ...? To 
> add to my confusion, Go functions can have as many return values as one 
> wishes just fine, ie. I obviously do not even understand what problem 
> you're trying to solve. Sorry.
>
>
> -- 
>
> -j
>

-- 
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] Extension for type assertion of interface array

[ankit . gupta]

Though the above is not allowed, you can restructure your code to wrap your 
struct as array in another struct and have area() paas a index to the 
underlying struct. Something like this (landSpaceArr wraps landSpace 
struct) - 

type landSpace struct{
side int
}

type landSpaceArr struct {
lS []landSpace
}

func (s *landSpaceArr) area(i int) int {
return s.lS[i].side * s.lS[i].side
}

type Shapes interface {
area(int) int
}

func main() {

v := make([]landSpace, 1)
v[0].side =50
a := {lS: v}

processShapes(a, 0)
}

func processShapes(shapes Shapes, i int) {

println(shapes.area(i))
}

~

On Thursday, April 19, 2018 at 10:29:12 AM UTC+5:30, Sakthi Natesan wrote:
>
> Usescases that I came across doesn't involve []interface{}. 
>
> My usecases will be similar to this sample code 
> 
>
> type landSpace struct {
> //consider that landSpace implements all functions from both Shape and 
> property interfaces
> ...
> }
> type Shape interface {
> ...
> }
>
>
> type property interface {
>
> ...
> }
>
>
> var a []*landSpace
>
> func processShapes(shapes []Shape) {
> //
> }
>
> func evaluateProperties(properties []Property) {
> //
> }
>
>
>
> If I want to pass the variable 'a' to both the functions, then I have to 
> write two functions to clone and typeAssert to respective interfaces.
>
>
> On Wednesday, 18 April 2018 19:53:33 UTC+5:30, Jan Mercl wrote:
>>
>> On Wed, Apr 18, 2018 at 4:13 PM  wrote:
>>
>> When possible, avoid using '[]interface{}' and use just 'interface{}' 
>> instead: https://play.golang.org/p/oPtPoGChkMZ.
>>
>>
>> -- 
>>
>> -j
>>
>
-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
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: parallel array processing question

[Egon]

When you have such questions, then run your code with the race 
detector. https://golang.org/doc/articles/race_detector.html

Otherwise, you are only reading from the slice, there is no racing possible.

Also, your max function looks very weird and has a small bug:
https://play.golang.org/p/8K-0ze3RdDt

The slice calculations has bugs as well, e.g. try running with 64 
goroutines.

+ Egon

On Thursday, 19 April 2018 14:35:20 UTC+3, l vic wrote:
>
> I have a program that calculates max value in integer array by breaking 
> the array into number of slices and calculating max in every slice inside 
> of go-routine.
> Do I still need to lock/unlock each slice with mutex inside of go-routine? 
> The code seems to be working but are any apparent problems with it?
>
> package main
>
>
> import (
>
> "fmt"
>
> "os"
>
> "strconv"
>
> "sync"
>
> )
>
>
> //returns maximum number found in provided slice
>
> func maxInSlice(numbers []uint) (uint, error) {
>
> if numbers == nil {
>
> return 0, fmt.Errorf("nil  numbers")
>
> }
>
>
> var max uint = 0
>
> for _, n := range numbers {
>
> for _, m := range numbers {
>
> if n > m {
>
> max = n
>
> }
>
> }
>
> }
>
>
> return max, nil
>
> }
>
>
> // finds  maximum  number  in  numbers  array  by   breaking  work  into  N  
> pieces
>
> // (where  N  is provided  as a command  line  argument)  and processing  the
>
> // pieces  in  parallel  goroutines func  main()
>
> func main() {
>
> parallelism, _ := strconv.Atoi(os.Args[1])
>
> fmt.Printf("ok,  i'll  use %d  goroutines\n", parallelism)
>
>
> numbers := []uint{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}
>
> wg := sync.WaitGroup{}
>
> mutex := sync.Mutex{}
>
> var allMax uint = 0
>
> perGoRoutine := len(numbers) / parallelism
>
> fmt.Printf("perGoRoutine=%d\n", perGoRoutine)
>
>
> for i := 0; i < parallelism; i++ {
>
> wg.Add(1)
>
> go func(i int) {
>
> defer wg.Done()
>
> fmt.Printf("==>index i = %d perGoRoutine in go func=%d\n", i, 
> perGoRoutine)
>
> startIndex := perGoRoutine * i
>
> endIndex := startIndex + perGoRoutine - 1
>
> //include last element
>
> if i == parallelism-1 {
>
> endIndex = len(numbers) - 1
>
>
> }
>
>
> fmt.Printf("startIndex=%d endIndex=%d\n", startIndex, endIndex)
>
> sliceMax, err := maxInSlice(numbers[startIndex:endIndex])
>
> mutex.Lock()
>
> if err != nil {
>
> fmt.Printf("error  finding  max  for  slice  %d  to  %d, 
> skipping  this  slice:  %s\n", err)
>
> return
>
> }
>
>
> fmt.Printf("goroutine  %d  (slice  %d  to  %d)  found  max  
> %d\n", i, startIndex, endIndex, sliceMax)
>
> if sliceMax > allMax {
>
> allMax = sliceMax
>
> }
>
> mutex.Unlock()
>
>
> }(i)
>
>
> }
>
> wg.Wait()
>
>
> fmt.Printf("maximum:  %d\n", allMax)
>
>
> }
>
>
>
>
>

-- 
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 "alt" attribute value for img tag?

[Victor L]

i am trying html Parse method from "html"* package but can't find element 
"img" ...*

*Any ideas?*

var f func(*html.Node)

f = func(n *html.Node) {

if n.Type == html.ElementNode { //&& n.Data == "alt" {

for _, a := range n.Attr {

//if a.Key == "img" {

fmt.Printf("a.key=%s a.val=%s\n", a.Key, a.Val)

break

//}

}

}

for c := n.FirstChild; c != nil; c = c.NextSibling {

f(c)

}

}

f(doc)

-- 
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: Why not tuples?

[Jan Mercl]

On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> Sorry for the self-promotion but it was relevant in that I was working on
how to tidy up the readability of my code and needed multiple returns and
simple untyped tuples were really not nearly as convenient as using a type
struct.

I have no idea what you mean by 'untyped tuples' because Go does not have
tuples, or at least not as a well defined thing. I can only guess if you're
trying to implement tuples in Go with an array, slice or a struct, ...? To
add to my confusion, Go functions can have as many return values as one
wishes just fine, ie. I obviously do not even understand what problem
you're trying to solve. Sorry.


-- 

-j

-- 
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] Go-path from a source other than $GOPATH (and package management)

[Paul Jolly]

I think you're getting at something similar to:

https://docs.google.com/document/d/1Ee8POHVeo3N6c1pgiubdWoUJoYkD5cwY3p8rqonRY0o/edit

Implemented roughly here:

https://github.com/myitcv/go

This was itself similar to/influenced by:

https://github.com/golang/go/issues/17271#issuecomment-268301191

In any case I think all of this becomes irrelevant in the context of vgo:

https://research.swtch.com/vgo

On 19 April 2018 at 13:48, Kaveh Shahbazian 
wrote:

> Is it possible to tell go tools to get the go-path from a source other
> than $GOPATH?
>
> Notes:
>
> Assuming the answer is no, I wish it was possible.
>
> For example when running a go command from the current directory, it go
> search the current directory, or goes up, until it finds a (for example)
> *.goenv* file, in which the GOPATH for current directory is specified.
>
> And the system-wide $GOPATH would act as a fall-back option, an umbrella
> root.
>
> This way the current project can have all of its stuff under the directory
> that contains the specified .goenv without interfering with other packages.
>
> Now if the current package (A) has two dependencies B and C and B uses a
> different version of C, then B can simply resides in a parallel directory
> to the current directory and be found in the system-wide $GOPATH.
>
> But go tools would always look for .goenv first.
>
> Seems to occupy the same amount of disk space as any other way of managing
> packages.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: http "alt" attribute value for img tag?

[matthewjuran]

I would start by isolating the alt=“…” string with splits 
(https://golang.org/pkg/strings/#Split) then use Sscanf 
(https://golang.org/pkg/fmt/#Sscanf) to parse the number. There may be 
other approaches like regular expressions.

Matt

On Wednesday, April 18, 2018 at 9:52:28 PM UTC-5, l vic wrote:
>
> I need to get "alt" value from html "img" tag:
>
> 
> ...
> message
>
> 
>
> 
>
> 
>
>
> 
>
> What would be the correct way in Go to read "alt" values into array?
>
> Thank you,
>
>
>
>

-- 
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: Why not tuples?

[Louki Sumirniy]

Just to clarify. Yes, the parent/child relationships are purely based on 
the indices of the nodes. It's not a conventional vector reference based 
binary tree. I was surprised when I came up with the idea that such did not 
even exist. Just to explain, it's a non-rectilinear array mapping. There is 
rows, and a root, and each row is double the size of the one above it. The 
name BAST comes from Bifurcation Array Search Tree. As far as I know it is 
the only non-linear/non-grid based ever invented. By me of course, so of 
course I am proud of it.

The coordinates stored in Cursor do not have any meaning except in a 
specific instance of the BAST array at a specific moment. I haven't worked 
out any strategies for multiple readers of the array, but I imagine it 
would just take a blocking table based on sections of the array, such as 4k 
pages or so, while the write process is changing it. Probably even, it's 
not possible to partially block read access for concurrency at all because 
many times write operations will stomp all over the tree in a random way 
because that's how hashes tend to be... random... Besides this, the atomic 
write operations generally won't block read access for long periods of time 
anyway. 

If I have piqued your curiosity, go check out the repo 
here: https://github.com/calibrae-project/bast - To sum it up in short 
words, it aims at eliminating retrieval latency caused by nonlinear seeking 
on memory devices. It has applicability to database lookup tables and 
should perform also quite well even on spinning disk cached stores (if they 
are allocated in one giant 2-4Gb blob).

Sorry for the self-promotion but it was relevant in that I was working on 
how to tidy up the readability of my code and needed multiple returns and 
simple untyped tuples were really not nearly as convenient as using a type 
struct. After doing a bunch of work on getting parametric polymorphism 
implemented in go, which is only obliquely relevant, I wrote a Gist about 
it: https://gist.github.com/l0k1verloren/469a4e467a2789daa04de60449af11cc 
No idea why nobody has written such a simple explanation and example of how 
to do it. You will spend 2 minutes on that and understand that actually, 
yes, you can do multiple inheritance in Go quite easily once you understand 
interface{} and parametric polymorphism is the simplest case.

On Thursday, 19 April 2018 08:31:01 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy  > wrote:
>
>>
>> func (b *Bast) Parent(c Cursor) Cursor {
>> if c.Index == 0 {
>> c.Err = errors.New("No parent from the root")
>> return c
>> }
>> c.Row--
>> c.Index = c.Index>>1 - (c.Index+1)%2
>> c.Err = nil
>> return c
>> }
>>
>
> This method looks like it should be defined be on *Cursor receiver, not 
> *Bast.
>
> -- 
>
> -j
>

-- 
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] go get -tags

[Kaveh Shahbazian]

How does *go get -tags* work?

-- 
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] Go-path from a source other than $GOPATH (and package management)

[Kaveh Shahbazian]

Is it possible to tell go tools to get the go-path from a source other than 
$GOPATH?

Notes:

Assuming the answer is no, I wish it was possible.

For example when running a go command from the current directory, it go 
search the current directory, or goes up, until it finds a (for example) 
*.goenv* file, in which the GOPATH for current directory is specified.

And the system-wide $GOPATH would act as a fall-back option, an umbrella 
root.

This way the current project can have all of its stuff under the directory 
that contains the specified .goenv without interfering with other packages.

Now if the current package (A) has two dependencies B and C and B uses a 
different version of C, then B can simply resides in a parallel directory 
to the current directory and be found in the system-wide $GOPATH.

But go tools would always look for .goenv first.

Seems to occupy the same amount of disk space as any other way of managing 
packages.

-- 
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: Why not tuples?

[Louki Sumirniy]

Ok, it may look like it but I don't want to track the cursor in the 
datatype itself most especially for reasons being that even one of the 
'sideways walk' functions in the library needs to keep a copy of the 
coordinate of the previous node iterated past in order to identify when the 
direction (left or right) changes, for specific (common) cases. The Bast is 
the data structure and contains all the data. Cursor is just a convenience 
way of storing the coordinate in the tree, the row of the coordinate and an 
easy way to return error values. So the 'cursor' has to be usable in 
external code, and external also to the data it points at, because there 
could be multiple trees being operated on within one application using this 
library.

On Thursday, 19 April 2018 08:31:01 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy  > wrote:
>
>>
>> func (b *Bast) Parent(c Cursor) Cursor {
>> if c.Index == 0 {
>> c.Err = errors.New("No parent from the root")
>> return c
>> }
>> c.Row--
>> c.Index = c.Index>>1 - (c.Index+1)%2
>> c.Err = nil
>> return c
>> }
>>
>
> This method looks like it should be defined be on *Cursor receiver, not 
> *Bast.
>
> -- 
>
> -j
>

-- 
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] go get -tags

[Jan Mercl]

On Thu, Apr 19, 2018 at 2:29 PM Kaveh Shahbazian 
wrote:

> How does go get -tags work?

`go get -tags foo example.com/bar` should be similar, but not always equal
to `go get -d example.com/bar && go install -tags foo example.com/bar`.

-- 

-j

-- 
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] parallel array processing question

[l vic]

I have a program that calculates max value in integer array by breaking the 
array into number of slices and calculating max in every slice inside of 
go-routine.
Do I still need to lock/unlock each slice with mutex inside of go-routine? 
The code seems to be working but are any apparent problems with it?

package main


import (

"fmt"

"os"

"strconv"

"sync"

)


//returns maximum number found in provided slice

func maxInSlice(numbers []uint) (uint, error) {

if numbers == nil {

return 0, fmt.Errorf("nil  numbers")

}


var max uint = 0

for _, n := range numbers {

for _, m := range numbers {

if n > m {

max = n

}

}

}


return max, nil

}


// finds  maximum  number  in  numbers  array  by   breaking  work  into  N  
pieces

// (where  N  is provided  as a command  line  argument)  and processing  the

// pieces  in  parallel  goroutines func  main()

func main() {

parallelism, _ := strconv.Atoi(os.Args[1])

fmt.Printf("ok,  i'll  use %d  goroutines\n", parallelism)


numbers := []uint{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}

wg := sync.WaitGroup{}

mutex := sync.Mutex{}

var allMax uint = 0

perGoRoutine := len(numbers) / parallelism

fmt.Printf("perGoRoutine=%d\n", perGoRoutine)


for i := 0; i < parallelism; i++ {

wg.Add(1)

go func(i int) {

defer wg.Done()

fmt.Printf("==>index i = %d perGoRoutine in go func=%d\n", i, 
perGoRoutine)

startIndex := perGoRoutine * i

endIndex := startIndex + perGoRoutine - 1

//include last element

if i == parallelism-1 {

endIndex = len(numbers) - 1


}


fmt.Printf("startIndex=%d endIndex=%d\n", startIndex, endIndex)

sliceMax, err := maxInSlice(numbers[startIndex:endIndex])

mutex.Lock()

if err != nil {

fmt.Printf("error  finding  max  for  slice  %d  to  %d, 
skipping  this  slice:  %s\n", err)

return

}


fmt.Printf("goroutine  %d  (slice  %d  to  %d)  found  max  %d\n", 
i, startIndex, endIndex, sliceMax)

if sliceMax > allMax {

allMax = sliceMax

}

mutex.Unlock()


}(i)


}

wg.Wait()


fmt.Printf("maximum:  %d\n", allMax)


}




-- 
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 debug internal package by gdb?

[Zhuo Meng]

I've figured that out

Turns out it's path is starts with vendor, not internal

(gdb) info functions
to show internal package file path

File 
/root/godev/src/vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20/chacha_arm64.s:
void 
vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20.block(void);
void 
vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20.block4(void);

(gdb) b vendor/golang_org/x/crypto/chacha20poly1305/internal/chacha20.block4
Breakpoint 1 at 0xe0840

@Ian Thanks for helping 



在 2018年4月17日星期二 UTC+8下午8:54:25，Ian Lance Taylor写道：
>
> On Tue, Apr 17, 2018 at 1:20 AM, Zhuo Meng  > wrote: 
> > 
> > I'm trying to write some internal package , but when I try to follow the 
> > code line by line using gdb. 
> > I found all the internal package are missing from breakpoint setting. 
> > 
> > How can I break on internal package? 
>
> There is nothing special about internal packages with regard to 
> debugging.  Are you completely sure that the package was imported by 
> your program?  Are you sure that the functions on which you are trying 
> to set a breakpoint are called? 
>
> 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] Fancy Comments & Documentation

[Dave Cheney]

Try putting a blank line between your comment block and the next symbol. This 
will break the association between the comment block and the symbol and hide 
the former. 

-- 
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] Fancy Comments & Documentation

[Jan Mercl]

On Thu, Apr 19, 2018 at 7:37 AM Chris FractalBach 
wrote:

> However, adding comments like this into Go code often ruins the
documentation, so I have been avoiding it.

Please specify what do you mean by "ruins the documentation". Do you have
an example that can be already seen somewhere in godoc.org?


-- 

-j

-- 
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] Fancy Comments & Documentation

[Harmen]

On Wed, Apr 18, 2018 at 10:37:26PM -0700, Chris FractalBach wrote:
> So, I'm one of those people who sometimes adds comments like this to my 
> code:
> 
> ++
> |   Program Title|
> |   Author   |
> |Date|
> ++
>  Synopsis, Description, etc.
> __
> 
> 
> However, adding comments like this into Go code often ruins the 
> documentation, so I have been avoiding it.
> Are there any solutions to get the best of both worlds?

If you indent that part of the comment it should end up in a  block.

Do note that godoc does give you headers if you do this:

> Each span of unindented non-blank lines is converted into a single paragraph.
> There is one exception to the rule: a span that consists of a single line, is
> followed by another paragraph span, begins with a capital letter, and contains
> no punctuation is formatted as a heading. 
https://golang.org/pkg/go/doc/#ToHTML

Maybe that helps enough.

-- 
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] sync.Cond implementation

[Penguin Enormous]

Much appreciated for all the great advises from everyone.

Or to be more precise: it is crucial you load wait before notify and the 
> check for equality can only happen if the routine "caught up". Also, your 
> proof must hold if you remove the fast-path check in line 522.
>

Why is it crucial to load wait before notify? May be I missed where wait is 
updated after notify to create happen-before relationship for the loads 
ordering to matter. Also, the fast-path you mention, should the proof be 
harder to produce if we introduce fast-path, as opposed to not having it in 
the first place.

I didn't mean to imply that data races are OK.  I meant that when 
> using condition variables, you have to be aware of the race conditions 
> between Wait and Signal/Broadcast, and you have to mitigate those race 
> conditions through correct use of the Locker associated with the 
> condition variable.  These race conditions are not data race 
> conditions, they are rather logical race conditions, in the sense that 
> if you do not correctly use the Locker then your goroutines can indeed 
> block forever in Wait. 
>

As I become aware of this race condition between waiters and signalers, is 
it enough to make sure that all increments to wait happen-before the signal 
call to avoid being blocked forever?

You are describing the possible race in terms of the runtime code, 
> which is the wrong level.
>

May be I am, but only if the documentation of higher level code provides 
sufficient information about stuff like possible races above. Most of the 
time when I learn about synchronization, I am forced to fallback to runtime 
code to make sense of hard-to-understand higher interfaces. Please don't 
misunderstand me, I am fully aware that good documentation for all levels 
of readers is very very hard to write so I absolutely don't blame anyone at 
all.

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