[go-nuts] [NOTE] GOPL type theory at the receiver

[John Pritchard]

The interface abstraction seems to be violated by the "pass by value"
convention at the receiver when the "I/O" pattern is found to be
dysfunctional.

In [IO] https://go.dev/play/p/9vx4HZpSYe0
we see that the implementation of an exemplar interface is functionally
stateless, demonstrating the appearance of self contradiction in GOPL type
theory.

type IO interface {

Read([]byte)

Write() []byte

}
type Bytes []byte

func (this Bytes) Read(src []byte) bool {

this = src

return 0 != len(this)

}
func (this Bytes) Write() []byte {

return this

}
func (this Bytes) String() string {

return string(this)

}

The case would seem to suggest that a reasonable increment of GOPL type
theory would consolidate the "*" hack onto a conception of "reference
types".

It would seem to be necessary and essential that the pointer reference type
glob at the receiver solve the disparity of point type object statelessness.


Best,

John

-- 
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/CAD6mcO9KbauDC%2BO5-qmdiLqkxtqb9bdcJu4kMWEVTqWE4qK7LQ%40mail.gmail.com.

[go-nuts] [NOTE] GOPL Type Theory

[John Pritchard]

Hi,

It occurs to me that GOPL type theory has a distinct benefit from its
constraint to the membership relation.  The external derivation of type
semantics has particular constraint.

Tools parsing GOPL expressions and systems are more readily capable of
reproducing type semantics.

The benefit of concise semantics to the universe external to GOPL "native"
interpretation may be represented as service and opportunity.

Meanwhile, the benefit of concise type semantics to the universe internal
to GOPL remains to be determined.


Best,

John


ps.  Interested in references to type theory conception, definition, and
review.

-- 
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/CAD6mcO-G1TwYJ4kdQh571Nu-VmqJPPqxASZzqgW3VaE6nA0TQA%40mail.gmail.com.

Re: [go-nuts] Any interest in nat.mulRange simplification/optimization?

[John Jannotti]

I wrote the single allocation version and added it to the issue, but Bakul
is absolutely right that the recursive solution has merit when the input is
large enough.  By building up large values on each "side" of the recursion,
Karatsuba gets used for the larger multiplies and the recursive version
begins to win. On `mulRange(1_000, 200_000)`, it's more than 20 times
faster than the single allocation iterative version.

I can put together a hybrid that uses iterative for shorter spans, and
recursive on larger, if that sounds interesting.

To get this off the mailing list, I will add this note to the issue, and
discussion can continue there. https://github.com/golang/go/issues/65027

On Mon, Jan 8, 2024 at 10:21 PM Bakul Shah  wrote:

> Perhaps you were thinking of this?
>
> At iteration number k, the value xk contains O(klog(k)) digits, thus the
> computation of xk+1 = kxk has cost O(klog(k)). Finally, the total cost
> with this basic approach is O(2log(2)+¼+n log(n)) = O(n2log(n)).
>
> A better approach is the *binary splitting* : it just consists in
> recursively cutting the product of m consecutive integers in half. It leads
> to better results when products on large integers are performed with a fast
> method.
>
> http://numbers.computation.free.fr/Constants/Algorithms/splitting.html
>
>
> I think you can do recursive splitting without using function recursion by
> allocating N/2 array (where b = a+N-1) and iterating over it; each time the
> array "shrinks" by half. A "cleverer" algorithm would allocate an array of
> *words* of a bignum, as you know that the upper limit on size is N*64 (for
> 64 bit numbers) so you can just reuse the same space for each outer
> iteration (N/2 multiplie, N/4 ...) and apply Karatsuba 2nd outer iteration
> onwards. Not sure if this is easy in Go.
>
> On Jan 8, 2024, at 11:47 AM, Robert Griesemer  wrote:
>
> Hello John;
>
> Thanks for your interest in this code.
>
> In a (long past) implementation of the factorial function, I noticed that
> computing a * (a+1) * (a+2) * ... (b-1) * b was much faster when computed
> in a recursive fashion than when computed iteratively: the reason (I
> believed) was that the iterative approach seemed to produce a lot more
> "internal fragmentation", that is medium-size intermediate results where
> the most significant word (or "limb" as is the term in other
> implementations) is only marginally used, resulting in more work than
> necessary if those words were fully used.
>
> I never fully investigated, it was enough at the time that the recursive
> approach was much faster. In retrospect, I don't quite believe my own
> theory. Also, that implementation didn't have Karatsuba multiplication, it
> just used grade-school multiplication.
>
> Since a, b are uint64 values (words), this could probably be implemented
> in terms of mulAddVWW directly, with a suitable initial allocation for the
> result - ideally this should just need one allocation (not sure how close
> we can get to the right size). That would cut down the allocations
> massively.
>
> In a next step, one should benchmark the implementation again.
>
> But at the very least, the overflow bug should be fixed, thanks for
> finding it! I will send out a CL to fix that today.
>
> Thanks,
> - gri
>
>
>
> On Sun, Jan 7, 2024 at 4:47 AM John Jannotti  wrote:
>
>> Actually, both implementations have bugs!
>>
>> The recursive implementation ends with:
>> ```
>> m := (a + b) / 2
>> return z.mul(nat(nil).mulRange(a, m), nat(nil).mulRange(m+1, b))
>> ```
>>
>> That's a bug whenever `(a+b)` overflows, making `m` small.
>> FIX: `m := a + (b-a)/2`
>>
>> My iterative implementation went into an infinite loop here:
>> `for m := a + 1; m <= b; m++ {`
>> if b is `math.MaxUint64`
>> FIX: add `&& m > a` to the exit condition is an easy fix, but pays a
>> small penalty for the vast majority of calls that don't have b=MaxUint64
>>
>> I would add these to `mulRangesN` of the unit test:
>> ```
>>  {math.MaxUint64 - 3, math.MaxUint64 - 1,
>> "6277101735386680760773248120919220245411599323494568951784"},
>> {math.MaxUint64 - 3, math.MaxUint64,
>> "115792089237316195360799967654821100226821973275796746098729803619699194331160"}
>> ```
>>
>> On Sun, Jan 7, 2024 at 6:34 AM John Jannotti  wrote:
>>
>>> I'm equally curious.
>>>
>>> FWIW, I realized the loop should perhaps be
>>> ```
>>> mb := nat(nil).setUint64(b) // ensure mb starts big enough for b, even
>>> on 32-bit arch
>>> for m := a + 1; m <= b; m++ {
>>>   mb.setUin

Re: [go-nuts] Any interest in nat.mulRange simplification/optimization?

[John Jannotti]

Actually, both implementations have bugs!

The recursive implementation ends with:
```
m := (a + b) / 2
return z.mul(nat(nil).mulRange(a, m), nat(nil).mulRange(m+1, b))
```

That's a bug whenever `(a+b)` overflows, making `m` small.
FIX: `m := a + (b-a)/2`

My iterative implementation went into an infinite loop here:
`for m := a + 1; m <= b; m++ {`
if b is `math.MaxUint64`
FIX: add `&& m > a` to the exit condition is an easy fix, but pays a small
penalty for the vast majority of calls that don't have b=MaxUint64

I would add these to `mulRangesN` of the unit test:
```
 {math.MaxUint64 - 3, math.MaxUint64 - 1,
"6277101735386680760773248120919220245411599323494568951784"},
{math.MaxUint64 - 3, math.MaxUint64,
"115792089237316195360799967654821100226821973275796746098729803619699194331160"}
```

On Sun, Jan 7, 2024 at 6:34 AM John Jannotti  wrote:

> I'm equally curious.
>
> FWIW, I realized the loop should perhaps be
> ```
> mb := nat(nil).setUint64(b) // ensure mb starts big enough for b, even on
> 32-bit arch
> for m := a + 1; m <= b; m++ {
>   mb.setUint64(m)
>   z = z.mul(z, mb)
> }
> ```
> to avoid allocating repeatedly for `m`, which yields:
> BenchmarkIterativeMulRangeN-10  354685  3032 ns/op2129 B/op
>48 allocs/op
>
> On Sun, Jan 7, 2024 at 2:41 AM Rob Pike  wrote:
>
>> It seems reasonable but first I'd like to understand why the recursive
>> method is used. I can't deduce why, but the CL that adds it, by gri, does
>> Karatsuba multiplication, which implies something deep is going on. I'll
>> add him to the conversation.
>>
>> -rob
>>
>>
>>
>>
>> On Sun, Jan 7, 2024 at 5:46 PM John Jannotti  wrote:
>>
>>> I enjoy bignum implementations, so I was looking through nat.go and saw
>>> that `mulRange` is implemented in a surprising, recursive way,.  In the
>>> non-base case, `mulRange(a, b)` returns `mulrange(a, (a+b)/2) *
>>> mulRange(1+(a+b)/2, b)` (lots of big.Int ceremony elided).
>>>
>>> That's fine, but I didn't see any advantage over the straightforward
>>> (and simpler?) for loop.
>>>
>>> ```
>>> z = z.setUint64(a)
>>> for m := a + 1; m <= b; m++ {
>>> z = z.mul(z, nat(nil).setUint64(m))
>>> }
>>> return z
>>> ```
>>>
>>> In fact, I suspected the existing code was slower, and allocated a lot
>>> more.  That seems true. A quick benchmark, using the existing unit test as
>>> the benchmark, yields
>>> BenchmarkRecusiveMulRangeN-10   169417   6856 ns/op 9452
>>> B/op  338 allocs/op
>>> BenchmarkIterativeMulRangeN-10   265354   4269 ns/op 2505
>>> B/op  196 allocs/op
>>>
>>> I doubt `mulRange` is a performance bottleneck in anyone's code! But it
>>> is exported as `int.MulRange` so I guess it's viewed with some value.  And
>>> seeing as how the for-loop seems even easier to understand that the
>>> recursive version, maybe it's worth submitting a PR? (If so, should I
>>> create an issue first?)
>>>
>>>
>>>
>>> --
>>> 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/e6ceb75a-f8b7-4f77-97dc-9445fb750782n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/e6ceb75a-f8b7-4f77-97dc-9445fb750782n%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/CALZHwko9GC7C_JThfVdFxBQtCmu9%2B%2BNYun8Tope4608oiio_6g%40mail.gmail.com.

Re: [go-nuts] Any interest in nat.mulRange simplification/optimization?

[John Jannotti]

I'm equally curious.

FWIW, I realized the loop should perhaps be
```
mb := nat(nil).setUint64(b) // ensure mb starts big enough for b, even on
32-bit arch
for m := a + 1; m <= b; m++ {
  mb.setUint64(m)
  z = z.mul(z, mb)
}
```
to avoid allocating repeatedly for `m`, which yields:
BenchmarkIterativeMulRangeN-10  354685  3032 ns/op2129 B/op
 48 allocs/op

On Sun, Jan 7, 2024 at 2:41 AM Rob Pike  wrote:

> It seems reasonable but first I'd like to understand why the recursive
> method is used. I can't deduce why, but the CL that adds it, by gri, does
> Karatsuba multiplication, which implies something deep is going on. I'll
> add him to the conversation.
>
> -rob
>
>
>
>
> On Sun, Jan 7, 2024 at 5:46 PM John Jannotti  wrote:
>
>> I enjoy bignum implementations, so I was looking through nat.go and saw
>> that `mulRange` is implemented in a surprising, recursive way,.  In the
>> non-base case, `mulRange(a, b)` returns `mulrange(a, (a+b)/2) *
>> mulRange(1+(a+b)/2, b)` (lots of big.Int ceremony elided).
>>
>> That's fine, but I didn't see any advantage over the straightforward (and
>> simpler?) for loop.
>>
>> ```
>> z = z.setUint64(a)
>> for m := a + 1; m <= b; m++ {
>> z = z.mul(z, nat(nil).setUint64(m))
>> }
>> return z
>> ```
>>
>> In fact, I suspected the existing code was slower, and allocated a lot
>> more.  That seems true. A quick benchmark, using the existing unit test as
>> the benchmark, yields
>> BenchmarkRecusiveMulRangeN-10   169417   6856 ns/op 9452 B/op
>>338 allocs/op
>> BenchmarkIterativeMulRangeN-10   265354   4269 ns/op 2505
>> B/op  196 allocs/op
>>
>> I doubt `mulRange` is a performance bottleneck in anyone's code! But it
>> is exported as `int.MulRange` so I guess it's viewed with some value.  And
>> seeing as how the for-loop seems even easier to understand that the
>> recursive version, maybe it's worth submitting a PR? (If so, should I
>> create an issue first?)
>>
>>
>>
>> --
>> 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/e6ceb75a-f8b7-4f77-97dc-9445fb750782n%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/e6ceb75a-f8b7-4f77-97dc-9445fb750782n%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/CALZHwkqd7ZQ6_VxYBJx8GWMjTLcqGo-3ausEC9rc21z3nHjyQA%40mail.gmail.com.

[go-nuts] Any interest in nat.mulRange simplification/optimization?

[John Jannotti]

I enjoy bignum implementations, so I was looking through nat.go and saw 
that `mulRange` is implemented in a surprising, recursive way,.  In the 
non-base case, `mulRange(a, b)` returns `mulrange(a, (a+b)/2) * 
mulRange(1+(a+b)/2, b)` (lots of big.Int ceremony elided).

That's fine, but I didn't see any advantage over the straightforward (and 
simpler?) for loop.

```
z = z.setUint64(a)
for m := a + 1; m <= b; m++ {
z = z.mul(z, nat(nil).setUint64(m))
}
return z
```

In fact, I suspected the existing code was slower, and allocated a lot 
more.  That seems true. A quick benchmark, using the existing unit test as 
the benchmark, yields
BenchmarkRecusiveMulRangeN-10   169417   6856 ns/op 9452 B/op   
   338 allocs/op
BenchmarkIterativeMulRangeN-10   265354   4269 ns/op 2505 B/op   
   196 allocs/op

I doubt `mulRange` is a performance bottleneck in anyone's code! But it is 
exported as `int.MulRange` so I guess it's viewed with some value.  And 
seeing as how the for-loop seems even easier to understand that the 
recursive version, maybe it's worth submitting a PR? (If so, should I 
create an issue first?)



-- 
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/e6ceb75a-f8b7-4f77-97dc-9445fb750782n%40googlegroups.com.

Re: [go-nuts] Re: [RFC] Syntactic Dissonance

[John Pritchard]

Hi,

With [VAR]
https://blog.merovius.de/posts/2018-06-03-why-doesnt-go-have-variance-in/
we review type diaspora into possibility space.  Perhaps the assertion that
the abstract operand is incapable of supporting the implications of its
communication.

Initially, [GST] https://github.com/syntelos/go-sort/blob/master/sort.go
had proposed that the abstraction deserving of review is captured by the
assignment operation.  The semantics of assignment are ambiguous.

Alternatively, parametric types displace the resolution of semantics from
static spacetime to dynamic spacetime.  Likewise, the conception of
semantics as dynamical.  That the Sort function semantics are related to
the dynamic operand type as well as the static function body.

See also [GSP] https://go.dev/ref/spec#Comparison_operators

FIXED in https://github.com/syntelos/go-sort/blob/master/sort.go
as in [PAR]
https://blog.merovius.de/posts/2024-01-05_constraining_complexity/
a problem solved via parametric type abstraction.

A fact which makes the case in favor of incrementing GOPL type theory.

Best,

John



On Sat, Jan 6, 2024 at 7:38 AM 'Brian Candler' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Full explanation here:
> https://blog.merovius.de/posts/2018-06-03-why-doesnt-go-have-variance-in/
>
> On Saturday 6 January 2024 at 11:55:27 UTC John Pritchard wrote:
>
>> Hi,
>>
>> Thinking about types and their conception, I could avoid the type
>> assertion boilerplate and rationalize the type membership relationship if
>> this code compiled.
>>
>> Best,
>>
>> John
>>
>>
>> On Sat, Jan 6, 2024 at 3:21 AM Tamás Gulácsi  wrote:
>>
>>> Where does TestObject implement the Comparable interface, esp. the
>>> Compare method?
>>> I don't see such in that rep.
>>> The implemented TestObject.Compare method has different signature: it
>>> requests a TestObject, not a Comparable interface, as your spec!
>>> This is only the first error.
>>>
>>> The second is that a slice of objects cannot be converted to a slice of
>>> interface - only by manually copying:
>>>
>>> ```
>>> diff --git a/sort_test.go b/sort_test.go
>>> index 0874721..c89b3b3 100644
>>> --- a/sort_test.go
>>> +++ b/sort_test.go
>>> @@ -13,10 +13,10 @@ type TestObject string
>>>
>>>  type TestList []TestObject
>>>
>>> -func (this TestObject) Compare(that TestObject) int {
>>> +func (this TestObject) Compare(that Comparable) int {
>>>
>>>   var bi, bj byte
>>> - var x, y, z int = 0, len(this), len(that)
>>> + var x, y, z int = 0, len(this), len(that.(TestObject))
>>>   var d, c int = 0, 0
>>>
>>>   if y == z {
>>> @@ -34,7 +34,7 @@ func (this TestObject) Compare(that TestObject) int {
>>>
>>>   for ; x < c; x++ {
>>>   bi = this[x]
>>> - bj = that[x]
>>> + bj = (that.(TestObject))[x]
>>>   if bi != bj {
>>>
>>>   if bi < bj {
>>> @@ -58,7 +58,11 @@ func (this TestList) Print() {
>>>  func TestSort(t *testing.T) {
>>>   var vector TestList = TestList{TestObject("20231219192613"),
>>> TestObject("20231221074246"), TestObject("20240102214104"),
>>> TestObject("20231222063428"), TestObject("20240104112200"),
>>> TestObject("20231217190339"), TestObject("20231213155157"),
>>> TestObject("20231219065525"), TestObject("20231231120412"),
>>> TestObject("20231221152849"), TestObject("20240102073948"),
>>> TestObject("20240101083455")}
>>>
>>> - Sort(vector)
>>> + objs := make([]Comparable, len(vector))
>>> + for i := range vector {
>>> + objs[i] = vector[i]
>>> + }
>>> + Sort(objs)
>>>
>>>   vector.Print()
>>>  }
>>> ```
>>> John Pritchard a következőt írta (2024. január 6., szombat, 8:53:01
>>> UTC+1):
>>>
>>>> Hi,
>>>>
>>>> Here's a case of "type dissonance" I don't understand.  Why should it
>>>> be?
>>>>
>>>> https://github.com/syntelos/go-sort
>>>>
>>>>
>>>> An interface type not passing through a static public package function
>>>> that employs the interface.
>>>>
>>>> type Comparable interface {
>>>>
>>>>
>>>> Compare(Comparable) int
>>>>
>>>> }
>>>>
>>>> func Sort(array []Comparable) ([]Comparabl

Re: [go-nuts] Re: [RFC] Syntactic Dissonance

[John Pritchard]

Hi,

Thinking about types and their conception, I could avoid the type assertion
boilerplate and rationalize the type membership relationship if this code
compiled.

Best,

John


On Sat, Jan 6, 2024 at 3:21 AM Tamás Gulácsi  wrote:

> Where does TestObject implement the Comparable interface, esp. the Compare
> method?
> I don't see such in that rep.
> The implemented TestObject.Compare method has different signature: it
> requests a TestObject, not a Comparable interface, as your spec!
> This is only the first error.
>
> The second is that a slice of objects cannot be converted to a slice of
> interface - only by manually copying:
>
> ```
> diff --git a/sort_test.go b/sort_test.go
> index 0874721..c89b3b3 100644
> --- a/sort_test.go
> +++ b/sort_test.go
> @@ -13,10 +13,10 @@ type TestObject string
>
>  type TestList []TestObject
>
> -func (this TestObject) Compare(that TestObject) int {
> +func (this TestObject) Compare(that Comparable) int {
>
>   var bi, bj byte
> - var x, y, z int = 0, len(this), len(that)
> + var x, y, z int = 0, len(this), len(that.(TestObject))
>   var d, c int = 0, 0
>
>   if y == z {
> @@ -34,7 +34,7 @@ func (this TestObject) Compare(that TestObject) int {
>
>   for ; x < c; x++ {
>   bi = this[x]
> - bj = that[x]
> + bj = (that.(TestObject))[x]
>   if bi != bj {
>
>   if bi < bj {
> @@ -58,7 +58,11 @@ func (this TestList) Print() {
>  func TestSort(t *testing.T) {
>   var vector TestList = TestList{TestObject("20231219192613"),
> TestObject("20231221074246"), TestObject("20240102214104"),
> TestObject("20231222063428"), TestObject("20240104112200"),
> TestObject("20231217190339"), TestObject("20231213155157"),
> TestObject("20231219065525"), TestObject("20231231120412"),
> TestObject("20231221152849"), TestObject("20240102073948"),
> TestObject("20240101083455")}
>
> - Sort(vector)
> + objs := make([]Comparable, len(vector))
> + for i := range vector {
> + objs[i] = vector[i]
> + }
> + Sort(objs)
>
>   vector.Print()
>  }
> ```
> John Pritchard a következőt írta (2024. január 6., szombat, 8:53:01 UTC+1):
>
>> Hi,
>>
>> Here's a case of "type dissonance" I don't understand.  Why should it be?
>>
>> https://github.com/syntelos/go-sort
>>
>>
>> An interface type not passing through a static public package function
>> that employs the interface.
>>
>> type Comparable interface {
>>
>>
>> Compare(Comparable) int
>>
>> }
>>
>> func Sort(array []Comparable) ([]Comparable)
>>
>>
>> With go-1.20.12:
>>
>> $ go test
>> # github.com/syntelos/go-sort [github.com/syntelos/go-sort.test]
>> ./sort_test.go:61:7: cannot use vector (variable of type TestList) as
>> []Comparable value in argument to Sort
>> FAILgithub.com/syntelos/go-sort [build failed]
>>
>>
>> Any comments?
>>
>> Best,
>>
>> John
>>
>>
>> --
> 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/ba7239c1-cb52-4f86-9e56-da6ffa721fa5n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/ba7239c1-cb52-4f86-9e56-da6ffa721fa5n%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/CAD6mcO-vyGwUQpuF66S%2B6mYQp5ZW6bV4hA3Gu8ofpk_8pZu4yg%40mail.gmail.com.

[go-nuts] [RFC] Syntactic Dissonance

[John Pritchard]

Hi,

Here's a case of "type dissonance" I don't understand.  Why should it be?

https://github.com/syntelos/go-sort


An interface type not passing through a static public package function that
employs the interface.

type Comparable interface {


Compare(Comparable) int

}

func Sort(array []Comparable) ([]Comparable)


With go-1.20.12:

$ go test
# github.com/syntelos/go-sort [github.com/syntelos/go-sort.test]
./sort_test.go:61:7: cannot use vector (variable of type TestList) as
[]Comparable value in argument to Sort
FAILgithub.com/syntelos/go-sort [build failed]


Any comments?

Best,

John

-- 
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/CAD6mcO9J-6bruuKTke%3DcOm8ZFRM%2BvSqEiWr62zTBGPeX0r3XLA%40mail.gmail.com.

[go-nuts] Re: Go 1.22 Release Candidate 1 is released

[John David Lee]

This is in the section titled "Why are yield functions limited to at most 
two arguments?"

On Sunday, December 24, 2023 at 5:43:23 PM UTC+1 John David Lee wrote:

> Hello.
>
> In the rangefunc experiment document 
> <https://go.dev/wiki/RangefuncExperiment> the iter package is said to 
> export the following:
>
> type Seq[V any] func(yield func(V) bool) bool 
> type Seq2[K, V any] func(yield func(K, V) bool) bool
>
> But after installing tip, it looks like the iter package exposes a 
> slightly different interface: 
>
> type Seq[V any] func(yield func(V) bool)
> type Seq2[K, V any] func(yield func(K, V) bool)
>
> Take care,
>
> David
> On Wednesday, December 20, 2023 at 12:43:36 AM UTC+1 anno...@golang.org 
> wrote:
>
>> Hello gophers,
>>
>> We have just released go1.22rc1, a release candidate version of Go 1.22.
>> It is cut from release-branch.go1.22 at the revision tagged go1.22rc1.
>>
>> Please try your production load tests and unit tests with the new version.
>> Your help testing these pre-release versions is invaluable.
>>
>> Report any problems using the issue tracker:
>> https://go.dev/issue/new
>>
>> If you have Go installed already, an easy way to try go1.22rc1
>> is by using the go command:
>> $ go install golang.org/dl/go1.22rc1@latest
>> $ go1.22rc1 download
>>
>> You can download binary and source distributions from the usual place:
>> https://go.dev/dl/#go1.22rc1
>>
>> To find out what has changed in Go 1.22, read the draft release notes:
>> https://tip.golang.org/doc/go1.22
>>
>> Cheers,
>> Than and Carlos for the Go team
>>
>

-- 
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/fe33a8dc-fbca-48a0-9320-ef383aec7a9en%40googlegroups.com.

[go-nuts] Re: Go 1.22 Release Candidate 1 is released

[John David Lee]

Hello.

In the rangefunc experiment document 
 the iter package is said to 
export the following:

type Seq[V any] func(yield func(V) bool) bool 
type Seq2[K, V any] func(yield func(K, V) bool) bool

But after installing tip, it looks like the iter package exposes a slightly 
different interface: 

type Seq[V any] func(yield func(V) bool)
type Seq2[K, V any] func(yield func(K, V) bool)

Take care,

David
On Wednesday, December 20, 2023 at 12:43:36 AM UTC+1 anno...@golang.org 
wrote:

> Hello gophers,
>
> We have just released go1.22rc1, a release candidate version of Go 1.22.
> It is cut from release-branch.go1.22 at the revision tagged go1.22rc1.
>
> Please try your production load tests and unit tests with the new version.
> Your help testing these pre-release versions is invaluable.
>
> Report any problems using the issue tracker:
> https://go.dev/issue/new
>
> If you have Go installed already, an easy way to try go1.22rc1
> is by using the go command:
> $ go install golang.org/dl/go1.22rc1@latest
> $ go1.22rc1 download
>
> You can download binary and source distributions from the usual place:
> https://go.dev/dl/#go1.22rc1
>
> To find out what has changed in Go 1.22, read the draft release notes:
> https://tip.golang.org/doc/go1.22
>
> Cheers,
> Than and Carlos for the Go team
>

-- 
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/014d606e-3f5c-44fa-8c92-b6ef41b21941n%40googlegroups.com.

[go-nuts] Re: Why doesn't the database/sql package in Go support using placeholders "?" to replace the database name and username in SQL statements?

[John Zh]

Thanks for your reply.
So does substituting placeholders in the driver still involve pre-compiling 
the SQL statement to prevent SQL injection? Acutally I am more concerned 
about security aspects rather than performance overhead.
在2023年9月19日星期二 UTC+8 07:45:35 写道：

> Hi. I'm maintainer of go-mysql-driver.
>
> There is an option to substitute placeholders in the driver, instead of in 
> the MySQL server.
> It can be used to:
>
> * Reduce roundtrip to execute a query
> * Avoid limitations of where placeholders can be used
>
>
>

-- 
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/08a09432-87a9-4c97-9a77-65dffaf4b466n%40googlegroups.com.

[go-nuts] Re: Why doesn't the database/sql package in Go support using placeholders "?" to replace the database name and username in SQL statements?

[John Zh]

Thanks for your reply. I understand now that the issue does not lie with 
the database/sql interface. It appears to be a limitation on the usage of 
placeholders in MySQL.
在2023年9月18日星期一 UTC+8 20:27:11 写道：

> Or else it's a prepared statement which gets invoked with parameters.
>
> Mysql's own documentation is unclear on where placeholders can be used: 
> https://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html
>
> Note that they give this example:
>
> mysql> SET @table = 't1'; mysql> SET @s = CONCAT('SELECT * FROM ', @table)
> ;
>
> mysql> PREPARE stmt3 FROM @s; mysql> EXECUTE stmt3;
>
> They don't do "SELECT * FROM ?" because you're not allowed to use a 
> placeholder for the table name - it must be inlined into the SQL. (And in 
> this example @table had better be from a trusted source, since they don't 
> do any quoting or escaping)
>
> On Monday, 18 September 2023 at 13:01:52 UTC+1 Vladimir Varankin wrote:
>
>> A thing, that it may be valuable to explain further, is that Go's 
>> "database/sql" doesn't come with a built-in query builder. 
>>
>> The package implements the database connection pooling/management, but it 
>> passes the user's SQL input and its arguments to the "driver". Depending on 
>> the particular database kind, the driver may or may not try to interpret 
>> the query (and the args), before it passes them to the database server.
>>
>> In the specific example of MySQL/MariaDB, the support for placeholder "?" 
>> is a part of this database's flavour of SQL. Thus, it's likely, the driver 
>> you're using, passes the query with a placeholder to the DB server, but the 
>> DB's support of placeholders is limited to only a subset of queries (or 
>> places inside a query) — as the link to SO's answer, shared previously, 
>> explained.
>>
>> Hope this makes it a little bit more clear.
>>
>> On Sunday, September 17, 2023 at 10:45:27 AM UTC+2 Brian Candler wrote:
>>
>>> According to this SO answer, CREATE USER in mysql doesn't support 
>>> placeholders:
>>>
>>> https://stackoverflow.com/questions/20647115/how-to-write-create-user-with-mysql-prepared-statement
>>> *"+1 for a legitmiate use of QUOTE() which is really the sanest thing 
>>> that can be done here, since CREATE USER doesn't support ? placeholders"*
>>>
>>> You can test this by trying a simple DML statement, e.g.
>>> UPDATE users SET name=? where name=?
>>>
>>> On Sunday, 17 September 2023 at 01:02:08 UTC+1 John Zh wrote:
>>>
>>>> Hi !
>>>> I am going to make some kind of manager app over MySQL clusters by 
>>>> using Golang. But I found that when I try to exec some SQL line includes 
>>>> user name or db name, the SQL line can't be correctly parameterized.
>>>> For example:
>>>> Using GORM based on database/sql or directly using database/sql
>>>> ```
>>>> err := db.Exec("CREATE USER ? IDENTIFIED BY ?", a.Name, a.Pwd).Error
>>>> ```
>>>> Got
>>>> ```
>>>> [1.824ms] [rows:0] CREATE USER 'Reiis' IDENTIFIED BY '12345'
>>>> Error 1064 (42000): You have an error in your SQL syntax; check the 
>>>> manual that corresponds to your MySQL server version for the right syntax 
>>>> to use near '? IDENTIFIED BY ?' at line 1
>>>> ```
>>>>
>>>> Seems like it does not replace "?" with a.Name, but rather passes the 
>>>> SQL command with "?" directly to MySQL.  What is more wired, it prints 
>>>> the SQL command with correctly replaced parameters in the log.
>>>>
>>>> I don't know the the underlying reason behind this phenomenon, is it 
>>>> intentionally designed like that?
>>>> Thx!
>>>>
>>>

-- 
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/0fdfe954-8297-40e1-a906-17a9d59b56a3n%40googlegroups.com.

[go-nuts] Re: Why doesn't the database/sql package in Go support using placeholders "?" to replace the database name and username in SQL statements?

[John Zh]

Thanks for your reply. You have deepened my understanding of placeholders. 
It seems to be the limitations of using placeholders in MySQL.
在2023年9月18日星期一 UTC+8 20:01:52 写道：

> A thing, that it may be valuable to explain further, is that Go's 
> "database/sql" doesn't come with a built-in query builder. 
>
> The package implements the database connection pooling/management, but it 
> passes the user's SQL input and its arguments to the "driver". Depending on 
> the particular database kind, the driver may or may not try to interpret 
> the query (and the args), before it passes them to the database server.
>
> In the specific example of MySQL/MariaDB, the support for placeholder "?" 
> is a part of this database's flavour of SQL. Thus, it's likely, the driver 
> you're using, passes the query with a placeholder to the DB server, but the 
> DB's support of placeholders is limited to only a subset of queries (or 
> places inside a query) — as the link to SO's answer, shared previously, 
> explained.
>
> Hope this makes it a little bit more clear.
>
> On Sunday, September 17, 2023 at 10:45:27 AM UTC+2 Brian Candler wrote:
>
>> According to this SO answer, CREATE USER in mysql doesn't support 
>> placeholders:
>>
>> https://stackoverflow.com/questions/20647115/how-to-write-create-user-with-mysql-prepared-statement
>> *"+1 for a legitmiate use of QUOTE() which is really the sanest thing 
>> that can be done here, since CREATE USER doesn't support ? placeholders"*
>>
>> You can test this by trying a simple DML statement, e.g.
>> UPDATE users SET name=? where name=?
>>
>> On Sunday, 17 September 2023 at 01:02:08 UTC+1 John Zh wrote:
>>
>>> Hi !
>>> I am going to make some kind of manager app over MySQL clusters by using 
>>> Golang. But I found that when I try to exec some SQL line includes user 
>>> name or db name, the SQL line can't be correctly parameterized.
>>> For example:
>>> Using GORM based on database/sql or directly using database/sql
>>> ```
>>> err := db.Exec("CREATE USER ? IDENTIFIED BY ?", a.Name, a.Pwd).Error
>>> ```
>>> Got
>>> ```
>>> [1.824ms] [rows:0] CREATE USER 'Reiis' IDENTIFIED BY '12345'
>>> Error 1064 (42000): You have an error in your SQL syntax; check the 
>>> manual that corresponds to your MySQL server version for the right syntax 
>>> to use near '? IDENTIFIED BY ?' at line 1
>>> ```
>>>
>>> Seems like it does not replace "?" with a.Name, but rather passes the 
>>> SQL command with "?" directly to MySQL.  What is more wired, it prints 
>>> the SQL command with correctly replaced parameters in the log.
>>>
>>> I don't know the the underlying reason behind this phenomenon, is it 
>>> intentionally designed like that?
>>> Thx!
>>>
>>

-- 
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/b0376b5e-2589-4810-918c-74336e940f30n%40googlegroups.com.

RE: [go-nuts] How ignore a subdirectory

['John Souvestre' via golang-nuts]

You are correct.  However, “gofmt .” recurses.  It turns out that they handle 
it differently.

 

John

 

John SouvestreNew Orleans LA, USA504-454-0899

 

From: golang-nuts@googlegroups.com  On Behalf Of 
Brian Candler
Sent: 2023-09-13, Wed 07:30
To: golang-nuts 
Subject: Re: [go-nuts] How ignore a subdirectory

 

I believe that "go fmt ." (note the space after "go") works on the current 
package only.

On Wednesday, 13 September 2023 at 11:34:35 UTC+1 Jan Mercl wrote:

On Wed, Sep 13, 2023 at 12:25 PM John Souvestre mailto:jo...@souvestre.com> > wrote:
> I did try that also.  I get this error message:
>
> CreateFile *.go: The filename, directory name, or volume label syntax is 
> incorrect.

Sorry, I'm not familiar with Windows and only TIL cmd.exe does not expand 
globs. I suggest to install WSL and try something like

 

C:\>bash -c 'gofmt *.go'

 

HTH

 

-- 
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 
<mailto:golang-nuts+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cf14f4f9-14fa-495e-905e-d7a62d8c070dn%40googlegroups.com
 
<https://groups.google.com/d/msgid/golang-nuts/cf14f4f9-14fa-495e-905e-d7a62d8c070dn%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/012f01d9e678%2489f2e040%249dd8a0c0%24%40Souvestre.com.

RE: [go-nuts] How ignore a subdirectory

['John Souvestre' via golang-nuts]

What is TIL?

 

Installing WSL just to solve this seems like it might be overkill.  A for loop 
in a batch file, or in DOSKEY, would suffice.

 

John

 

John SouvestreNew Orleans LA, USA504-454-0899

 

From: Jan Mercl <0xj...@gmail.com> 
Sent: 2023-09-13, Wed 05:33
To: John Souvestre 
Cc: golang-nuts@googlegroups.com
Subject: Re: [go-nuts] How ignore a subdirectory

 

On Wed, Sep 13, 2023 at 12:25 PM John Souvestre mailto:j...@souvestre.com> > wrote:
> I did try that also.  I get this error message:
>
> CreateFile *.go: The filename, directory name, or volume label syntax is 
> incorrect.

Sorry, I'm not familiar with Windows and only TIL cmd.exe does not expand 
globs. I suggest to install WSL and try something like

 

C:\>bash -c 'gofmt *.go'

 

HTH

 

-- 
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/012a01d9e678%243ed46070%24bc7d2150%24%40Souvestre.com.

RE: [go-nuts] How ignore a subdirectory

['John Souvestre' via golang-nuts]

I did try that also.  I get this error message:

CreateFile *.go: The filename, directory name, or volume label syntax is 
incorrect.

John

John SouvestreNew Orleans LA, USA504-454-0899

-Original Message-
From: Jan Mercl <0xj...@gmail.com> 
Sent: 2023-09-13, Wed 01:31
To: John Souvestre 
Cc: golang-nuts@googlegroups.com
Subject: Re: [go-nuts] How ignore a subdirectory

On Wed, Sep 13, 2023 at 5:47�AM 'John Souvestre' via golang-nuts
 wrote:

> I�m trying to run gofmt on all of the .go files in a directory, but not any 
> subdirectories.

$ gofmt *.go

-- 
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/00f201d9e62c%24a6c5a320%24f450e960%24%40Souvestre.com.

[go-nuts] How ignore a subdirectory

['John Souvestre' via golang-nuts]

I’m trying to run gofmt on all of the .go files in a directory, but not any 
subdirectories.  I have tried using “.” for the target.  It does get all of the 
.go in the current directory, but it also does all the .go files in 
subdirectories.  To be more specific: There is one particular subdirectory 
which I don’t want it to process: “_Save”.

 

The https://pkg.go.dev/cmd/go documentation says:

 

Directory and file names that begin with "." or "_" are ignored by the go tool, 
as are directories named "testdata".

 

I have used this in the past and it worked fine.  But it doesn’t seem to work 
now.

 

Besides “_Save”, I tried “.Save” and even “testdata”.  It processed all of 
them.  The command I am using is “gofmt -d .”.

 

The files in the “_Save” subdirectory are not part of my program’s build, some 
of them are .go files.  There are no references to them in my code, however.

 

Am I misunderstanding something?  Or not doing something correctly?

 

I’m doing this on Windows 10, by the way.

 

Thanks,

 

John

 

John SouvestreNew Orleans LA, USA504-454-0899

 

-- 
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/00e601d9e5f5%2404b17ff0%240e147fd0%24%40Souvestre.com.

Re: [go-nuts] Re: [rfc] build bug in type abstraction?

[John Pritchard]

Hi Brian,

Thanks for the review.  Your basic conclusion matches mine, that the
./main/main.go:46 and ./types.go are proven in the "go run" case, and
disproven in the "go build" case.

Best,

John


On Wed, Aug 16, 2023 at 9:58 AM Brian Candler  wrote:

> On Wednesday, 16 August 2023 at 14:05:49 UTC+1 John Pritchard wrote:
>
> I have a disparity between "go run" [
> https://go.dev/play/p/5mr5M0luZ9k?v=goprev]
> and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].
> Using go version 1.21.0.
>
>
> I don't quite understand where "go run" comes into this.  In your Makefile
> <https://github.com/syntelos/go-type-abstraction/blob/third/Makefile>,
> both options use "go build".
>
> "make list" is doing something dubious:
>
> go_sources := $(shell ls *.go)
> ...
> list: main/main.go $(go_sources)
> go build -o $@ $<
>
> That is, I think you're trying to compile "main/main.go" and "types.go" at
> the same time into a single object file.  But types.go is "package types"
> whereas main.go is "package main".  That should give you an error; if it
> doesn't, that makes me suspect that go_sources is in fact empty.  The "make
> list" output you show in README.txt appears to confirm this:
>
> $ make
> go build -o list main/main.go# <<< note that no additional sources are
> listed on the command line
>
> In main.go, there is a pretty clear error that the compiler calls out in
> line 46:
> main/main.go:46:15: undefined: Abstract
>
> The corresponding source line
> <https://github.com/syntelos/go-type-abstraction/blob/third/main/main.go#L46>
> is:
> var abstract Abstract = types.Init()
>
> and as far as I can see, it's correct: you have no type "Abstract" in
> package main in main.go (in otherwise, you should be referring to
> "types.Abstract")
>
>
> --
> 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/a0716bee-a6b9-4ea7-b4a7-165c4ef43fabn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/a0716bee-a6b9-4ea7-b4a7-165c4ef43fabn%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/CAD6mcO85tazOOrykPzp0XEg7FRfT7vKDLSk-fevrFm7sxMGaCQ%40mail.gmail.com.

[go-nuts] [rfc] build bug in type abstraction?

[John Pritchard]

Hi,

I have a disparity between "go run" [
https://go.dev/play/p/5mr5M0luZ9k?v=goprev]
and "go build" [https://github.com/syntelos/go-type-abstraction/tree/third].
Using go version 1.21.0.

A fairly simple structure of type abstraction works on play.go.dev, but
fails to build.

Comments?  Issue?

Thanks,

John

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

[go-nuts] go11tag

[John Pritchard]

Hello,

Debugging "go build" with dlv, which hungup at 

go/src/cmd/go/main.go:92:var _ = go11tag

Looking around a bit, found no particular rationale for the existence of 
"go11tag".

Best,

John

-- 
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/93a38771-14ad-4f33-a5a2-fd0e842cb04fn%40googlegroups.com.

[go-nuts] Is OCSP Stapling supported in Go? If so, how?

[John Wayne]

I tried to google this for a while now, and all I find regarding this topic 
is: https://groups.google.com/g/golang-nuts/c/QC5FOysyVxg

This is already many years old, and to me it seems like there is code 
inside Go which allows to perform server side OCSP stapling. However, I am 
unable to find out *how* one would use this. Does this just work 
transparently in the background, all done by the Go library itself, or does 
the developer need to take measures when implementing an HTTP server using 
Go?

I would test this out myself, but testing whether or not a given server 
provides the OCSP response in the handshake is not exactly trivial, since 
you would need to have a proper certificate with a working OCSP responder 
set up, which I don't.

So I would really appreciate if someonce could shed a bit of light on this 
topic for me.

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/99634c56-6357-48b8-887f-9d27067182fan%40googlegroups.com.

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

[John]

Note for posterity:

Other methods of method equality fall in the same problem, such as detailed 
in:
https://stackoverflow.com/questions/9643205/how-do-i-compare-two-functions-for-pointer-equality-in-the-latest-go-weekly

Proof: https://go.dev/play/p/aeeRKfderY2

On Monday, November 7, 2022 at 10:09:26 AM UTC-8 John wrote:

> Thanks Ian for being generous with your time in answering this.  I'll see 
> if I can drum up another way to make that check work. 
>
> Cheers and have a good rest of your day.
> On Monday, November 7, 2022 at 10:02:28 AM UTC-8 Ian Lance Taylor wrote:
>
>> On Mon, Nov 7, 2022 at 9:24 AM John  wrote:
>> >
>> > Or maybe I'm just doing something wrong.
>> >
>> > I have a struct implementing generics where methods return the next 
>> method to execute.
>> >
>> > For tests, I wanted to make sure the returned method was the one 
>> expected, so I was using this:
>> >
>> > nextStageName := 
>> runtime.FuncForPC(reflect.ValueOf(nextStage).Pointer()).Name()
>> > (where "nextStage" is the next method)
>> >
>> > Here is a simple non-generic version where I get what I expect:
>> > https://go.dev/play/p/kimGRS7xiP2
>> >
>> > result: main.(*AStruct).NextStage-fm):
>> >
>> > Here is probably a slightly convoluted generic version that does not:
>> > https://go.dev/play/p/TUHUaZywki0
>> >
>> > result: main.(*GenericStruct[...]).Stage.func1
>> >
>> > In that version, it seem to give me the name of the method that 
>> returned the next method.
>> >
>> > Any idea what is (or what I'm doing) wrong?
>>
>> I'm not sure that runtime.FuncForPC is going to work here. What it is
>> reporting is a function literal defined within the Stage method (that
>> is what the "func1" means). What is happening is that the Stage
>> method is returning a function literal that invokes the NextStage
>> method. This is due to details of how generic functions are compiled,
>> and may change from release to release. In general FuncForPC is a
>> fairly low level operation that has no way to avoid these sorts of
>> compilation details. I don't know if there is a way to do what you
>> want to do.
>>
>> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bf7f9802-0dd6-4ef0-ad7c-fbc6ba00feb4n%40googlegroups.com.

Re: [go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

[John]

Thanks Ian for being generous with your time in answering this.  I'll see 
if I can drum up another way to make that check work. 

Cheers and have a good rest of your day.
On Monday, November 7, 2022 at 10:02:28 AM UTC-8 Ian Lance Taylor wrote:

> On Mon, Nov 7, 2022 at 9:24 AM John  wrote:
> >
> > Or maybe I'm just doing something wrong.
> >
> > I have a struct implementing generics where methods return the next 
> method to execute.
> >
> > For tests, I wanted to make sure the returned method was the one 
> expected, so I was using this:
> >
> > nextStageName := 
> runtime.FuncForPC(reflect.ValueOf(nextStage).Pointer()).Name()
> > (where "nextStage" is the next method)
> >
> > Here is a simple non-generic version where I get what I expect:
> > https://go.dev/play/p/kimGRS7xiP2
> >
> > result: main.(*AStruct).NextStage-fm):
> >
> > Here is probably a slightly convoluted generic version that does not:
> > https://go.dev/play/p/TUHUaZywki0
> >
> > result: main.(*GenericStruct[...]).Stage.func1
> >
> > In that version, it seem to give me the name of the method that returned 
> the next method.
> >
> > Any idea what is (or what I'm doing) wrong?
>
> I'm not sure that runtime.FuncForPC is going to work here. What it is
> reporting is a function literal defined within the Stage method (that
> is what the "func1" means). What is happening is that the Stage
> method is returning a function literal that invokes the NextStage
> method. This is due to details of how generic functions are compiled,
> and may change from release to release. In general FuncForPC is a
> fairly low level operation that has no way to avoid these sorts of
> compilation details. I don't know if there is a way to do what you
> want to do.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ab2b391f-fd9c-4384-b349-2db97e704fd6n%40googlegroups.com.

[go-nuts] Generics: Using runtime.FuncForPC() to get method name doesn't *seem* to work

[John]

Or maybe I'm just doing something wrong.

I have a struct implementing generics where methods return the next method 
to execute.

For tests, I wanted to make sure the returned method was the one expected, 
so  I was using this:

nextStageName := 
runtime.FuncForPC(reflect.ValueOf(nextStage).Pointer()).Name()
(where "nextStage" is the next method) 

Here is a simple non-generic version where I get what I expect:
https://go.dev/play/p/kimGRS7xiP2

result: main.(*AStruct).NextStage-fm):

Here is probably a slightly convoluted generic version that does not:
https://go.dev/play/p/TUHUaZywki0

result: main.(*GenericStruct[...]).Stage.func1

In that version, it seem to give me the name of the method that returned 
the next method.

Any idea what is (or what I'm doing) wrong?

Cheers.



-- 
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/105a412e-c7df-424f-931c-d25443aa7c80n%40googlegroups.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

[John]

Thank you everyone who responded.  Gave utter a look and its pretty 
decent.  I found litter a bit more developed around the circular reference 
area.  But both were great suggestions and just what I was looking for.

Again, thank you for helping me find these!

On Monday, August 15, 2022 at 3:59:05 PM UTC-7 kortschak wrote:

> On Mon, 2022-08-15 at 07:26 -0700, John wrote:
> > I know we have plenty of pretty printing out there, but i'm looking
> > for a package that can print the Go representation of a Struct out to
> > screen.
> >
> > So given:
> >
> > var x := {
> >   A: "hello"
> > }
> >
> > someLib.Print(x)
> >
> > I get:
> >
> > {
> >   A: "hello"
> > }
> >
> > I'm sure someone has used reflection to do this and figured out how
> > they want to deal with recursive pointers, so don't want to go
> > recreate the wheel here.
> >
> > Thanks.
>
> github.com/kortschak/utter will do this for most values (there are
> cases that are not possible due to requiring programmatic construction
> — pointers to strings, ints etc, and filled channels being examples).
>
> Dan
>
>

-- 
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/666011b3-d5ed-4528-9a41-e626ac84ab8bn%40googlegroups.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

[John]

Hey axel,

I recognize the problem space you are discussing. There are a couple 
strategies I could implement to try and solve the problems.  And I'm not 
100% sure you can solve all of them.  But I certainly don't want to jump 
down the rabbit hole of reflection myself if I don't have to.  So I'm 
looking for a package that has attempted to do this.  I'd certainly take 
something that can't handle every case.

So far my googlefoo hasn't found the key words that differentiate this from 
pretty printing, or this type of package doesn't exist.

Thanks for your response axel.



On Monday, August 15, 2022 at 7:53:16 AM UTC-7 axel.wa...@googlemail.com 
wrote:

> I don't believe this is possible, in general. For example, consider
>
> type S struct {
> A *int
> B *int
> }
> var x S
> x.A = new(int)
> x.B = x.A
>
> There is no single expression for the value of x. Or
>
> type P *P
> x := new(P)
> *x = x
>
> Then you have values which represent more than just their plain memory 
> resources. For example, an *os.File - restoring that would not give you the 
> same thing.
>
> There's lots of design space here and I don't think you can solve it in 
> full generality. So, at the very least, you have to be very deliberate 
> about what you want and what you are willing to give up.
>
> But. Maybe someone else has suggestions for a library doing an 
> approximation of this you'd like better.
>
>
> On Mon, Aug 15, 2022 at 4:42 PM John  wrote:
>
>> Hey axel,
>>
>> Thanks for the reply, but unfortunately not. Because that is going to 
>> simply print pointer values out.  I want it to unwind all of that (and 
>> handle the difficulty of recursive references).  I want to be able to take 
>> what is printed and simply paste it into a file assigned to a variable, add 
>> the needed imports and have it compile.
>>
>> On Monday, August 15, 2022 at 7:34:08 AM UTC-7 axel.wa...@googlemail.com 
>> wrote:
>>
>>> Does fmt.Printf("%#v", v) do what you want?
>>>
>>> On Mon, Aug 15, 2022 at 4:27 PM John  wrote:
>>>
>>>> I know we have plenty of pretty printing out there, but i'm looking for 
>>>> a package that can print the Go representation of a Struct out to screen.
>>>>
>>>> So given:
>>>>
>>>> var x := {
>>>>   A: "hello"
>>>> }
>>>>
>>>> someLib.Print(x)
>>>>
>>>> I get:
>>>>
>>>> {
>>>>   A: "hello"
>>>> }
>>>>
>>>> I'm sure someone has used reflection to do this and figured out how 
>>>> they want to deal with recursive pointers, so don't want to go recreate 
>>>> the 
>>>> wheel here.
>>>>
>>>> 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...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/golang-nuts/f4fa3f7b-318e-407b-96ef-16102db1e037n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/golang-nuts/f4fa3f7b-318e-407b-96ef-16102db1e037n%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/2029ba81-dbf5-44c2-ac9f-228dcb7837f4n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/2029ba81-dbf5-44c2-ac9f-228dcb7837f4n%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/0e2af167-4bad-49a1-8a12-e5218204b47fn%40googlegroups.com.

Re: [go-nuts] Library for printing a struct as a compiler recognized version

[John]

Hey axel,

Thanks for the reply, but unfortunately not. Because that is going to 
simply print pointer values out.  I want it to unwind all of that (and 
handle the difficulty of recursive references).  I want to be able to take 
what is printed and simply paste it into a file assigned to a variable, add 
the needed imports and have it compile.

On Monday, August 15, 2022 at 7:34:08 AM UTC-7 axel.wa...@googlemail.com 
wrote:

> Does fmt.Printf("%#v", v) do what you want?
>
> On Mon, Aug 15, 2022 at 4:27 PM John  wrote:
>
>> I know we have plenty of pretty printing out there, but i'm looking for a 
>> package that can print the Go representation of a Struct out to screen.
>>
>> So given:
>>
>> var x := {
>>   A: "hello"
>> }
>>
>> someLib.Print(x)
>>
>> I get:
>>
>> {
>>   A: "hello"
>> }
>>
>> I'm sure someone has used reflection to do this and figured out how they 
>> want to deal with recursive pointers, so don't want to go recreate the 
>> wheel here.
>>
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f4fa3f7b-318e-407b-96ef-16102db1e037n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f4fa3f7b-318e-407b-96ef-16102db1e037n%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/2029ba81-dbf5-44c2-ac9f-228dcb7837f4n%40googlegroups.com.

[go-nuts] Library for printing a struct as a compiler recognized version

[John]

I know we have plenty of pretty printing out there, but i'm looking for a 
package that can print the Go representation of a Struct out to screen.

So given:

var x := {
  A: "hello"
}

someLib.Print(x)

I get:

{
  A: "hello"
}

I'm sure someone has used reflection to do this and figured out how they 
want to deal with recursive pointers, so don't want to go recreate the 
wheel here.

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/f4fa3f7b-318e-407b-96ef-16102db1e037n%40googlegroups.com.

[go-nuts] Using Go Lang as a tiny server program at localhost , won't execute request

[John Dutcher]

I have a tiny server program in Go language (main2.go) running and 
'listening' on port 8080 in a Windows command prompt session. While running 
I point a browser to http://localhost:8080/main2.go and main2.go executes 
and places a small html form into the browser window to fill and submit. If 
the form ACTION has any requested target for some other Go program or HTML 
element resident in the same Windows folder as main2.go, the element 
request is ignored  ONLY 'main2.go' gets triggered to execute instead 
in response to the POST request 'submitted'.

I have tried all variations I can think of in the POST ACTION URL format to 
get the POST to run an element in the Windows folder called 'main.go' 
(instead of main2.go):

ACTION examples:
http://localhost:8080/main.go
localhost:8080/main.go
/main.go
../main.go
./main.go

BUT, if I load the ACTION URL with something like 'https://www.google.com' 
it brings the home page for Google right into the browser window no problem.

Why can it not run main.go, which again, resides in the same Windows folder 
as main2.go which is the Go program running as the swerver ?

-- 
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/8ae6812d-a551-429d-ab6b-5215063a60a2n%40googlegroups.com.

[go-nuts] Re: Using generics to solve Optional argument problem for multiple methods

[John]

Thanks Henry and Harry.

This helped expose me to some other options. The only thing about these is 
they don't particularly look user friendly (which I didn't ask for).  I've 
streamlined my version (non-generic) out to this:
https://github.com/johnsiilver/calloptions . The godoc has an explanation 
on how to use it.  

It gives type safety and limits which calls can be used.  It also looks 
exactly to the user like the normal functional arguments. It only has two 
problems (that I see):

   - It is complicated to implement, a newbie maintainer of some package is 
   going to have no idea what's happening
   - There is a single *any* in that gets passed to the Do() method

This *any* should be fine in this case, because you'd have to add support 
for a method but not implement it for it to be a runtime problem.  But it 
still irks me that I can't get it to a compile time check.

Thank you both for being generous with your time.

Cheers!


On Thursday, July 28, 2022 at 12:57:50 PM UTC-7 harr...@spu.edu wrote:

> There's a trivial conversion from any shared option to a flavored 
> optionFunc[T]:
>
> type optionFunc[T any] func(*client)
>
> func reflavor[T any]( shared func(*client)) optionFunc[T] {
> return optionFunc[T](shared)
> }
>
> I'm not sure exactly where reflavoring shared -> optionFunc[T] would fit 
> in best, my first approach might be that the optionStructA and 
> optionStructB could return appropriately flavored slices []optionFunc[A], 
> []optionFunc[B].
>
> Then, the A(), B() methods can accept only the right option flavor:
>
> func (c *client) A( ...option[A])
> func (c *client) B( ...option[B])
> On Wednesday, July 27, 2022 at 9:44:15 PM UTC-7 Henry wrote:
>
>> ```
>> type WithSharedOption interface {
>>SomeMethod()
>> }
>>
>> type OptionA struct {
>> }
>>
>> func (a OptionA) SomeMethod(){}
>>
>> type OptionB struct {
>> }
>>
>> func (b OptionB) SomeMethod(){}
>>
>> //without generics
>> func WithShared(option WithSharedOption){}
>> func WithANotShared(option OptionA){}
>>
>> //with generics
>> func WithShared[T WithSharedOption](option T){}
>> func WithANotShared(option OptionA){}
>> ```
>>
>> On Thursday, July 28, 2022 at 6:12:16 AM UTC+7 John wrote:
>>
>>> As a note, this is how I solve this problem without generics:
>>>
>>> https://go.dev/play/p/nsDca0McADY
>>>
>>> On Wednesday, July 27, 2022 at 2:54:20 PM UTC-7 John wrote:
>>>
>>>> With 1.18 generics, I'm curious if anyone has a good solution using 
>>>> generics to solve the optional argument that can be used in multiple 
>>>> method 
>>>> problem.
>>>>
>>>> So say I have two methods, .A() and .B().  Both accept optional 
>>>> arguments where some optional arguments might be shared.
>>>>
>>>> Here is a very loose (do not take any of this as the solution, just 
>>>> trying to show what I'm kinda trying to achieve). 
>>>>
>>>> type AOptions struct{
>>>>   Shared Opt string
>>>>   NotSharedOpt bool
>>>> }
>>>>
>>>> type BOptions struct{
>>>>   Shared Opt string
>>>>   NotSharedOpt int
>>>> }
>>>>
>>>> func WithShared(shared string) CallOption {
>>>>   ...
>>>> }
>>>>
>>>> func WithANotShared(b bool) CallOption {
>>>>   ...
>>>> }
>>>>
>>>> func (c Client) A(options ...CallOption) {
>>>>   opts := AOptions{}
>>>>   for _, o := range options {
>>>> o()
>>>>   }
>>>>   ... 
>>>> }
>>>> func (c Client B(options ...CalOption) {
>>>>   ...
>>>> }
>>>>
>>>> We want to be able to use WithShared() with both A() and B(), but only  
>>>> WithANotShared with the A() method.  
>>>>
>>>> I've had different solutions to this problem that would give runtime 
>>>> errors, but I'm curious with generics if there is one for compile time 
>>>> that 
>>>> anyone has come up with.
>>>>
>>>> Cheers.
>>>>
>>>

-- 
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/24a4245d-e73e-4a5c-bd3d-dacc8382dbcan%40googlegroups.com.

[go-nuts] Re: Using generics to solve Optional argument problem for multiple methods

[John]

As a note, this is how I solve this problem without generics:

https://go.dev/play/p/nsDca0McADY

On Wednesday, July 27, 2022 at 2:54:20 PM UTC-7 John wrote:

> With 1.18 generics, I'm curious if anyone has a good solution using 
> generics to solve the optional argument that can be used in multiple method 
> problem.
>
> So say I have two methods, .A() and .B().  Both accept optional arguments 
> where some optional arguments might be shared.
>
> Here is a very loose (do not take any of this as the solution, just trying 
> to show what I'm kinda trying to achieve). 
>
> type AOptions struct{
>   Shared Opt string
>   NotSharedOpt bool
> }
>
> type BOptions struct{
>   Shared Opt string
>   NotSharedOpt int
> }
>
> func WithShared(shared string) CallOption {
>   ...
> }
>
> func WithANotShared(b bool) CallOption {
>   ...
> }
>
> func (c Client) A(options ...CallOption) {
>   opts := AOptions{}
>   for _, o := range options {
> o()
>   }
>   ... 
> }
> func (c Client B(options ...CalOption) {
>   ...
> }
>
> We want to be able to use WithShared() with both A() and B(), but only  
> WithANotShared with the A() method.  
>
> I've had different solutions to this problem that would give runtime 
> errors, but I'm curious with generics if there is one for compile time that 
> anyone has come up with.
>
> Cheers.
>

-- 
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/61967fec-929a-4865-80ff-14ab25a1d39dn%40googlegroups.com.

[go-nuts] Using generics to solve Optional argument problem for multiple methods

[John]

With 1.18 generics, I'm curious if anyone has a good solution using 
generics to solve the optional argument that can be used in multiple method 
problem.

So say I have two methods, .A() and .B().  Both accept optional arguments 
where some optional arguments might be shared.

Here is a very loose (do not take any of this as the solution, just trying 
to show what I'm kinda trying to achieve). 

type AOptions struct{
  Shared Opt string
  NotSharedOpt bool
}

type BOptions struct{
  Shared Opt string
  NotSharedOpt int
}

func WithShared(shared string) CallOption {
  ...
}

func WithANotShared(b bool) CallOption {
  ...
}

func (c Client) A(options ...CallOption) {
  opts := AOptions{}
  for _, o := range options {
o()
  }
  ... 
}
func (c Client B(options ...CalOption) {
  ...
}

We want to be able to use WithShared() with both A() and B(), but only  
WithANotShared with the A() method.  

I've had different solutions to this problem that would give runtime 
errors, but I'm curious with generics if there is one for compile time that 
anyone has come up with.

Cheers.

-- 
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/31042a26-83b0-40af-b5ae-811a2e893033n%40googlegroups.com.

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

[John]

Just as a follow-up, I think the answer to this question is to fork the 
net/http library to add a line that handles an error type ErrIgnore without 
the ramifications of a temporary error.  With all the good and bad that it 
entails (for this use case, it should be fine).

This is just a niche use case, I can't imagine a change to support this 
getting into the net/http package.  

On Monday, March 28, 2022 at 8:28:31 PM UTC-7 John wrote:

> Hey Sean and Robert,
>
> Thanks for the suggestions. 
>
> I can see how the temporary error would work, but as Sean is saying, this 
> is going to add delays that are going to go against what I'm wanting to do. 
>
> Sean, I'm not sure I understand the part about looping my code.  Here is a 
> sample on the playground, is it possible you can show me what I'm missing:
> https://go.dev/play/p/_B4jkTzWcS0
>
> Cheers.
>
> On Mon, Mar 28, 2022 at 4:47 PM 'Sean Liao' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> abusing temporary delays like that could result in unpredictable 
>> performance with up to a second between accepts, not something you want if 
>> you are flooded with things you want to deny (which is what an ACL is for).
>>
>> On Mon, Mar 28, 2022, 23:46 robert engels  wrote:
>>
>>> You just need to return a temporary error. It should not be exiting 
>>> anyway - unless the “done” channel is valid.
>>>
>>> ctx := context.WithValue(baseCtx, ServerContextKey, srv)
>>> for {
>>>rw, err := l.Accept()
>>>if err != nil {
>>>   select {
>>>   case <-srv.getDoneChan():
>>>  return ErrServerClosed
>>>   default:
>>>   }
>>>   if ne, ok := err.(net.Error); ok && ne.Temporary() {
>>>  if tempDelay == 0 {
>>> tempDelay = 5 * time.Millisecond
>>>  } else {
>>> tempDelay *= 2
>>>  }
>>>  if max := 1 * time.Second; tempDelay > max {
>>> tempDelay = max
>>>  }
>>>  srv.logf("http: Accept error: %v; retrying in 
>>> %v", err, tempDelay)
>>>  time.Sleep(tempDelay)
>>>  continue
>>>   }
>>>   return err
>>>}
>>>
>>>
>>>
>>> On Mar 28, 2022, at 5:35 PM, 'Sean Liao' via golang-nuts <
>>> golan...@googlegroups.com> wrote:
>>>
>>> I would just add a for loop around your code and only return when you 
>>> have a connection you want to allow, otherwise just log / pass the error 
>>> elsewhere.
>>>
>>>
>>> On Mon, Mar 28, 2022 at 11:26 PM John  wrote:
>>>
>>>> I'm looking to satisfy this:
>>>>
>>>>- If you are in an ACL, you can make a TLS connection
>>>>- If you are not in an ACL, you can only a TCP connection, but not 
>>>>a TLS connection*
>>>>
>>>> ** It would be better if it didn't honor TCP either, unless it is a 
>>>> health probe*
>>>>
>>>> Basically I want to move my denials into the listener and not in the 
>>>> http.Server handlers.
>>>>
>>>> I thought I was clever recently, trying to do this with:
>>>>
>>>> func (a *aclListener) Accept() (net.Conn, error) {
>>>> conn, err := a.ln.Accept()
>>>> if err != nil {
>>>> return nil, err
>>>> }
>>>>
>>>> host, _, err := net.SplitHostPort(conn.RemoteAddr().String())
>>>> if err != nil {
>>>> return nil, fmt.Errorf("connection's remote address(%s) could not be 
>>>> split: %s", conn.RemoteAddr().String(), err)
>>>> }
>>>>
>>>> // The probe connected, so close the connection and exit.
>>>> if a.acls.isProbe(host) {
>>>> log.Printf("TCP probe(%s) connection", host)
>>>> conn.Close()
>>>> return nil, ErrIsProbe
>>>> }
>>>>
>>>>   // Block anything that isn't in our ACL.
>>>> if err := a.acls.ipAuth(host); err != nil {
>>>> return nil, err
>>>> }
>>>> log.Println("accepting connection from: ", conn.RemoteAddr().String())
>>>> return conn, nil
>>>> }
>>>>
>>>> aclListener implements a net.Listener and I was going to allow the TCP 
>>>> probe from this
>>>> health service, but nothing more (like seeing the TLS header).
>>>

[go-nuts] TODO comments in net/lookup_windows.go

[John Dreystadt]

Being a newbie to Go, I spent some time reading some of the standard 
packages and noticed a large number of TODO comments in lookup_windows.go. 
So I decided to see if I could resolve these comments. I now have a 
 working proof of concept for lookupIP standalone and maybe I should be 
working to contribute these changes. But I don't see any issues associated 
with these TODO comments. Should I create one or more issues or has a 
decision been made to not address these comments?

-- 
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/60be5d1f-8031-4c55-9161-610290d0b881n%40googlegroups.com.

Re: [go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

[John Doak]

Hey Sean and Robert,

Thanks for the suggestions.

I can see how the temporary error would work, but as Sean is saying, this
is going to add delays that are going to go against what I'm wanting to do.

Sean, I'm not sure I understand the part about looping my code.  Here is a
sample on the playground, is it possible you can show me what I'm missing:
https://go.dev/play/p/_B4jkTzWcS0

Cheers.

On Mon, Mar 28, 2022 at 4:47 PM 'Sean Liao' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> abusing temporary delays like that could result in unpredictable
> performance with up to a second between accepts, not something you want if
> you are flooded with things you want to deny (which is what an ACL is for).
>
> On Mon, Mar 28, 2022, 23:46 robert engels  wrote:
>
>> You just need to return a temporary error. It should not be exiting
>> anyway - unless the “done” channel is valid.
>>
>> ctx := context.WithValue(baseCtx, ServerContextKey, srv)
>> for {
>>rw, err := l.Accept()
>>if err != nil {
>>   select {
>>   case <-srv.getDoneChan():
>>  return ErrServerClosed
>>   default:
>>   }
>>   if ne, ok := err.(net.Error); ok && ne.Temporary() {
>>  if tempDelay == 0 {
>> tempDelay = 5 * time.Millisecond
>>  } else {
>> tempDelay *= 2
>>  }
>>  if max := 1 * time.Second; tempDelay > max {
>> tempDelay = max
>>  }
>>  srv.logf("http: Accept error: %v; retrying in
>> %v", err, tempDelay)
>>  time.Sleep(tempDelay)
>>  continue
>>   }
>>   return err
>>}
>>
>>
>>
>> On Mar 28, 2022, at 5:35 PM, 'Sean Liao' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> I would just add a for loop around your code and only return when you
>> have a connection you want to allow, otherwise just log / pass the error
>> elsewhere.
>>
>>
>> On Mon, Mar 28, 2022 at 11:26 PM John  wrote:
>>
>>> I'm looking to satisfy this:
>>>
>>>- If you are in an ACL, you can make a TLS connection
>>>- If you are not in an ACL, you can only a TCP connection, but not a
>>>TLS connection*
>>>
>>> ** It would be better if it didn't honor TCP either, unless it is a
>>> health probe*
>>>
>>> Basically I want to move my denials into the listener and not in the
>>> http.Server handlers.
>>>
>>> I thought I was clever recently, trying to do this with:
>>>
>>> func (a *aclListener) Accept() (net.Conn, error) {
>>> conn, err := a.ln.Accept()
>>> if err != nil {
>>> return nil, err
>>> }
>>>
>>> host, _, err := net.SplitHostPort(conn.RemoteAddr().String())
>>> if err != nil {
>>> return nil, fmt.Errorf("connection's remote address(%s) could not be
>>> split: %s", conn.RemoteAddr().String(), err)
>>> }
>>>
>>> // The probe connected, so close the connection and exit.
>>> if a.acls.isProbe(host) {
>>> log.Printf("TCP probe(%s) connection", host)
>>> conn.Close()
>>> return nil, ErrIsProbe
>>> }
>>>
>>>   // Block anything that isn't in our ACL.
>>> if err := a.acls.ipAuth(host); err != nil {
>>> return nil, err
>>> }
>>> log.Println("accepting connection from: ", conn.RemoteAddr().String())
>>> return conn, nil
>>> }
>>>
>>> aclListener implements a net.Listener and I was going to allow the TCP
>>> probe from this
>>> health service, but nothing more (like seeing the TLS header).
>>> However, it turns out erroring on an Accept() will cause the http.Server
>>> to stop.
>>>
>>> Of course, if this code did work, the difference between the prober and
>>> non-ACL connections is the same, they both can get the TCP socket
>>> before being denied.
>>>
>>> Does anyone know if I can achieve this in my code without getting super
>>> hacky? I can see
>>> some ways to that, but figured someone here might have done this in a
>>> simple way.
>>>
>>> Cheers and 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+unsu

[go-nuts] Allow a TCP connection, but not a TLS connection based on an ACL

[John]

I'm looking to satisfy this:

   - If you are in an ACL, you can make a TLS connection
   - If you are not in an ACL, you can only a TCP connection, but not a TLS 
   connection*

** It would be better if it didn't honor TCP either, unless it is a health 
probe*

Basically I want to move my denials into the listener and not in the 
http.Server handlers.

I thought I was clever recently, trying to do this with:

func (a *aclListener) Accept() (net.Conn, error) {
conn, err := a.ln.Accept()
if err != nil {
return nil, err
}

host, _, err := net.SplitHostPort(conn.RemoteAddr().String())
if err != nil {
return nil, fmt.Errorf("connection's remote address(%s) could not be split: 
%s", conn.RemoteAddr().String(), err)
}

// The probe connected, so close the connection and exit.
if a.acls.isProbe(host) {
log.Printf("TCP probe(%s) connection", host)
conn.Close()
return nil, ErrIsProbe
}

  // Block anything that isn't in our ACL.
if err := a.acls.ipAuth(host); err != nil {
return nil, err
}
log.Println("accepting connection from: ", conn.RemoteAddr().String())
return conn, nil
}

aclListener implements a net.Listener and I was going to allow the TCP 
probe from this
health service, but nothing more (like seeing the TLS header).
However, it turns out erroring on an Accept() will cause the http.Server to 
stop.

Of course, if this code did work, the difference between the prober and 
non-ACL connections is the same, they both can get the TCP socket before 
being denied.

Does anyone know if I can achieve this in my code without getting super 
hacky? I can see
some ways to that, but figured someone here might have done this in a 
simple way.

Cheers and 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/4ab235c1-ab52-42de-a22a-a31bde21eb0cn%40googlegroups.com.

[go-nuts] Limit the number of goroutine while using errgroup

[Reach John]

How to control the number of goroutines when using errgroup? Is there a 
best practice?

-- 
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/3920c043-787e-439b-b92a-fdbf2971n%40googlegroups.com.

[go-nuts] New Releases: Command Line Interface Generator tool for Go

[John Brown]

Just released Gofire, a tool for Go that automatically generates a command 
line interface (CLI) for your functions and does all required plumbing in 
between, inspired by *https://github.com/google/python-fire.*

*https://github.com/1pkg/gofire*

   - Gofire uses code generation to generate simple and predictable CLI 
   tailored to your code. It takes care about all required plumbing around 
   parameters parsing, types casting, setting the entrypoint, documentation, 
   etc.
   - Gofire provides multiple CLI backends with different capabilities and 
   features, including: flag, cobra, bubbletea.
   - Gofire is opinionated about the defaults and always tries to provide 
   simple and safe CLI. Yet, if needed, it supports optional go structs tag 
   literals to flexibly configure CLI parameters.

-- 
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/430e8221-3197-4498-bbe1-c469226ffb38n%40googlegroups.com.

[go-nuts] gctrace vs MemStats

[John Rusk]

How do the heap sizes output by gctrace map to the various values of 
MemStats? I assume that the heap values from gctrace roughly match *one* (or 
two?) of the MemStats fields, but I can't find anything that documents that.

I see in the code that the gctrace outputs are mostly based 
on heap_live and the MemStats values are not (directly) based on the the 
same thing... but I'm guessing there's an indirect or approximate link. 

(I'm a bit puzzled by some gctrace output that I'm seeing.)

John

-- 
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/b3306813-dcfe-4551-95a2-8b768161cc77n%40googlegroups.com.

Re: [go-nuts] Is embed.FS not expected to be walkable by fs.WalkDir()?

[John]

Thanks for that axel.  I had tried "./" and "/".  I guess I missed one :)
On Sunday, June 20, 2021 at 11:53:03 PM UTC-7 axel.wa...@googlemail.com 
wrote:

> You need to pass "." to `fs.WalkDir`, not "".
>
> On Mon, Jun 21, 2021 at 7:42 AM John  wrote:
>
>> package main
>>
>> import (
>> "embed"
>> "io/fs"
>> "log"
>> )
>>
>> //go:embed somefile.txt
>> var FS embed.FS
>>
>> func main() {
>>   err := fs.WalkDir(
>> FS,
>> "",
>> func(path string, d fs.DirEntry, err error) error {
>>   log.Println("path: ", path)
>>   return nil
>> },
>>   )
>>
>>   if err != nil {
>> log.Println("err: ", err)
>>   }
>> }
>>
>> This will output a single empty long line:
>>
>> 2021/06/20 22:32:29 path:  
>>
>> d comes set to nil, which seems to be a valid condition according to the 
>> docs:
>>
>> *First, if the initial fs.Stat on the root directory fails, WalkDir calls 
>> the function with path set to root, d set to nil, and err set to the error 
>> from fs.Stat.*
>>
>> This seems like an undesirable outcome to be unable to walk the embed.FS, 
>> but I figure maybe it doesn't do so to only allow absolute paths for speed?
>>
>>
>>
>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/1b00707c-9f4e-45de-87a8-0cbdda1e2fd4n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/1b00707c-9f4e-45de-87a8-0cbdda1e2fd4n%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/53e85c05-9df7-48bc-b080-df7c41f7f81bn%40googlegroups.com.

[go-nuts] Is embed.FS not expected to be walkable by fs.WalkDir()?

[John]

package main

import (
"embed"
"io/fs"
"log"
)

//go:embed somefile.txt
var FS embed.FS

func main() {
  err := fs.WalkDir(
FS,
"",
func(path string, d fs.DirEntry, err error) error {
  log.Println("path: ", path)
  return nil
},
  )

  if err != nil {
log.Println("err: ", err)
  }
}

This will output a single empty long line:

2021/06/20 22:32:29 path:  

d comes set to nil, which seems to be a valid condition according to the 
docs:

*First, if the initial fs.Stat on the root directory fails, WalkDir calls 
the function with path set to root, d set to nil, and err set to the error 
from fs.Stat.*

This seems like an undesirable outcome to be unable to walk the embed.FS, 
but I figure maybe it doesn't do so to only allow absolute paths for speed?




-- 
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/1b00707c-9f4e-45de-87a8-0cbdda1e2fd4n%40googlegroups.com.

Re: [go-nuts] I think I found a bug?

[John Olson]

Thank you!
So it seems I misunderstood what append() does. I expected that all of the 
slices I had created with append() would have just enough capacity, such that 
every use of append() would allocate new memory and copy. It surprises me that 
my code worked as well as it did.

J 

> On May 26, 2021, at 21:51, Jamil Djadala  wrote:
> 
> minimally changed code that works:
> 
> https://play.golang.org/p/Tcfw_EC8jMp
> 
> 
> On Thursday, May 27, 2021 at 4:11:40 AM UTC+3 johnfor...@gmail.com wrote:
> Here’s the code. <https://play.golang.org/p/JYXqCWsXeIj> It might be possible 
> to come up with a shorter reproducer, but I’m not sure where to start. The 
> recursion takes place in line 21. The code works for 7 or smaller, and fails 
> for 8 and larger.
> 
> J
> 
> 
>> On May 26, 2021, at 20:34, Martin Schnabel > > wrote:
>> 
>> Could you send a https://play.golang.org/ <https://play.golang.org/> link 
>> showing a short example?
>> 
>> Without much information it sounds like a you update the same slice at two 
>> different indices. It would be interesting to know how you populate the temp 
>> slice.
>> 
>> On 27.05.21 01:52, John Olson wrote:
>>> I have a recursive function that seems to be reusing memory it shouldn't. 
>>> I'm developing in Goland 2021.1.1 with go version 1.16.2.
>>> I've written a function to generate the partitions of an integer. The 
>>> partitions of n are all the sets of integers that add up to n, so the 
>>> partitions of 3 are {3}, {2,1} and {1,1,1}. As n grows, the number of 
>>> partitions grows exponentially (to be precise, as e^(n^½)). I wrote a 
>>> recursive function, which works great up to n=7. At n=8, one of the 
>>> partitions is {2,2,2,1}, which is obviously wrong; and since the function 
>>> is recursive, every subsequent n is wrong, too.
>>> I just spent quite a long time stepping through the code, and I found that 
>>> what seems to be happening is that a slice declared in my recursive 
>>> function is being reused in two different recursions. Specifically, my 
>>> function declares
>>> var temp [][]int
>>> to build up the list of partitions. When I compute Partitions(8), I have to 
>>> compute Partitions(4), 5, 6 and 7. I memoize each set of partitions so I 
>>> only have to compute them once.
>>> It all goes wrong when I'm working on Partitions(7). At this point, 
>>> Partitions(8) has already added 6 cases, the last of which is {2,2,2,2}. 
>>> This is stored in temp[5], the temp corresponding to n=8, of course. Then I 
>>> compute Partitions(7), which should create a new temp [][]int; I'll call 
>>> this temp//7. temp[6]//7 gets {2,2,2,1}, and at that point temp[5]//8 
>>> changes from {2,2,2,2} to {2,2,2,1}. The addresses of temp[6]//7 and 
>>> temp[5]//8 are different, but the addresses of the /elements/ of these 
>>> slices are the same.
>>> This has to be wrong.
>>> I suspect a bug in go, but I suppose it's possible there's a bug in goland. 
>>> I'm running on macOS 11.3.1, just in case that's relevant.
>>> I'm happy to share the source code if anyone is interested.
>>> Thanks,
>>> 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...@googlegroups.com 
>>>  
>>> <mailto:golang-nuts...@googlegroups.com 
>>> >.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com>
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com?utm_medium=email_source=footer
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com?utm_medium=email_source=footer>>.
> 
> 
> -- 
> 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/MPQWVYruhlU/unsubscribe 
> <https://groups.google.com/d/topic/golang-nuts/MPQWVYruhlU/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegr

Re: [go-nuts] I think I found a bug?

[John Olson]

Here’s the code. <https://play.golang.org/p/JYXqCWsXeIj> It might be possible 
to come up with a shorter reproducer, but I’m not sure where to start. The 
recursion takes place in line 21. The code works for 7 or smaller, and fails 
for 8 and larger.

J

> On May 26, 2021, at 20:34, Martin Schnabel  wrote:
> 
> Could you send a https://play.golang.org/ <https://play.golang.org/> link 
> showing a short example?
> 
> Without much information it sounds like a you update the same slice at two 
> different indices. It would be interesting to know how you populate the temp 
> slice.
> 
> On 27.05.21 01:52, John Olson wrote:
>> I have a recursive function that seems to be reusing memory it shouldn't. 
>> I'm developing in Goland 2021.1.1 with go version 1.16.2.
>> I've written a function to generate the partitions of an integer. The 
>> partitions of n are all the sets of integers that add up to n, so the 
>> partitions of 3 are {3}, {2,1} and {1,1,1}. As n grows, the number of 
>> partitions grows exponentially (to be precise, as e^(n^½)). I wrote a 
>> recursive function, which works great up to n=7. At n=8, one of the 
>> partitions is {2,2,2,1}, which is obviously wrong; and since the function is 
>> recursive, every subsequent n is wrong, too.
>> I just spent quite a long time stepping through the code, and I found that 
>> what seems to be happening is that a slice declared in my recursive function 
>> is being reused in two different recursions. Specifically, my function 
>> declares
>> var temp [][]int
>> to build up the list of partitions. When I compute Partitions(8), I have to 
>> compute Partitions(4), 5, 6 and 7. I memoize each set of partitions so I 
>> only have to compute them once.
>> It all goes wrong when I'm working on Partitions(7). At this point, 
>> Partitions(8) has already added 6 cases, the last of which is {2,2,2,2}. 
>> This is stored in temp[5], the temp corresponding to n=8, of course. Then I 
>> compute Partitions(7), which should create a new temp [][]int; I'll call 
>> this temp//7. temp[6]//7 gets {2,2,2,1}, and at that point temp[5]//8 
>> changes from {2,2,2,2} to {2,2,2,1}. The addresses of temp[6]//7 and 
>> temp[5]//8 are different, but the addresses of the /elements/ of these 
>> slices are the same.
>> This has to be wrong.
>> I suspect a bug in go, but I suppose it's possible there's a bug in goland. 
>> I'm running on macOS 11.3.1, just in case that's relevant.
>> I'm happy to share the source code if anyone is interested.
>> Thanks,
>> 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 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com> 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com>
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com?utm_medium=email_source=footer
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%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/85343A4B-C179-4F52-86B3-57D30D8F149D%40gmail.com.

[go-nuts] I think I found a bug?

[John Olson]

I have a recursive function that seems to be reusing memory it shouldn't. 
I'm developing in Goland 2021.1.1 with go version 1.16.2.

I've written a function to generate the partitions of an integer. The 
partitions of n are all the sets of integers that add up to n, so the 
partitions of 3 are {3}, {2,1} and {1,1,1}. As n grows, the number of 
partitions grows exponentially (to be precise, as e^(n^½)). I wrote a 
recursive function, which works great up to n=7. At n=8, one of the 
partitions is {2,2,2,1}, which is obviously wrong; and since the function 
is recursive, every subsequent n is wrong, too.

I just spent quite a long time stepping through the code, and I found that 
what seems to be happening is that a slice declared in my recursive 
function is being reused in two different recursions. Specifically, my 
function declares
var temp [][]int
to build up the list of partitions. When I compute Partitions(8), I have to 
compute Partitions(4), 5, 6 and 7. I memoize each set of partitions so I 
only have to compute them once.

It all goes wrong when I'm working on Partitions(7). At this point, 
Partitions(8) has already added 6 cases, the last of which is {2,2,2,2}. 
This is stored in temp[5], the temp corresponding to n=8, of course. Then I 
compute Partitions(7), which should create a new temp [][]int; I'll call 
this temp//7. temp[6]//7 gets {2,2,2,1}, and at that point temp[5]//8 
changes from {2,2,2,2} to {2,2,2,1}. The addresses of temp[6]//7 and 
temp[5]//8 are different, but the addresses of the *elements* of these 
slices are the same.

This has to be wrong.

I suspect a bug in go, but I suppose it's possible there's a bug in goland. 
I'm running on macOS 11.3.1, just in case that's relevant.

I'm happy to share the source code if anyone is interested.

Thanks,

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fb9031ba-bfa0-4c92-9cb7-6ad3a8781184n%40googlegroups.com.

Re: [go-nuts] Code Review Checklist: Go Concurrency

[John Dreystadt]

As still quite the newbie at Go, I agree about the usefulness. Several
years ago I ran into a paper on this subject at a blog called the Morning
Paper (sadly gone quiet). The paper itself is at
https://songlh.github.io/paper/go-study.pdf . It has some examples and
might be a useful addition to the list of reading materials.

JohnD

On Tue, Mar 23, 2021 at 6:29 PM Ian Lance Taylor  wrote:

> On Sun, Mar 21, 2021 at 1:22 PM Roman Leventov 
> wrote:
> >
> > I've created a list of possible concurrency-related bugs and gotchas in
> Go code: https://github.com/code-review-checklists/go-concurrency.
> >
> > The idea of this list is to accompany
> https://github.com/golang/go/wiki/CodeReviewComments and
> https://golang.org/doc/articles/race_detector#Typical_Data_Races (my list
> actually refers to a couple of data races described in the list of "Typical
> Data Races").
> >
> > Comments, corrections, additions are welcome!
> >
> > If there are some core Go developers reading this, I would also like to
> know if you think some of the points from my list can be moved to
> https://github.com/golang/go/wiki/CodeReviewComments.
>
> Thanks.  This seems useful.  It's not quite the kind of thing that we
> have on the CodeReviewComments page, which is more about style than
> correctness.  I think it would be fine as another wiki page, or where
> you already have 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWBJEYNFo-o5VpaoSFMcx9kfivENcR9Di-dh1-ZhdLg6w%40mail.gmail.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/CAP%3DUbLeG70uqqLU1GR2bXPG5KosMTHn_oznM9S6L0yb-buX8EA%40mail.gmail.com.

[go-nuts] Possible issue in docs for Listen and ListenPacket

[John Dreystadt]

The documentation for  func (*ListenConfig) Listen ends with the line "See 
func Listen for a description of the network and address parameters". The 
next function called ListenPacket has the same line with the name changed 
to ListenPacket. I think that these should actually say "See func Dial 
for a description of the network and address parameters". Can someone show 
me what I am missing? If not, I can open an issue.

-- 
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/ed7c2188-dea2-49c6-b3b6-310cbf393245n%40googlegroups.com.

[go-nuts] New generic purpose throttler library for Go that comes with builtin integrations for popular Go libraries

[John Brown]

Library has vast amount of different built throttler conditions, among 
which are:
- leaky-bucket
- latency threshold
- metrics
- etc.
Library allows to easily combine them into more complex throttling 
pipelines and also ships tools to easily integrate it into existing 
infrastructure, for e.g. gohalt provides the way to bind throttler to 
`context`. As it stated library also has number of integrations with 
popular Go libraries: gin, http, echo, iris, grpc, go-micro, and many more.
Check it out https://github.com/1pkg/gohalt

-- 
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/a066b87c-64ba-485b-9184-d98281e5f377n%40googlegroups.com.

[go-nuts] Wasm test code, how to use syscall/js to create a document when invoked in node.js

[John]

I am using the following to run wasm tests:

GOOS=js GOARCH=wasm go test -exec "node $(go env GOROOT)/misc/wasm/wasm_exec

Because I'm in a node environment, the Global().Get("document") is empty.

I need to be able to populate that with the correct document object so I 
can test DOM manipulation.  However, I am not sure how to do this.  The 
document needs to be some specific object type and not a string 
representing the page,  which I could achieve with .Set(string).

In javascript, I believe you can do:
document.implementation.createHTMLDocument()

Anyone know if this is possible to do from syscall/js and if so how to do 
this?

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/89fae903-8933-49b2-8418-4d711bae7c0dn%40googlegroups.com.

Re: [go-nuts] What should be a silly protoc golang question

[John]

Mathew + Burak,

That was it.  

Out of curiosity, where did you find that option.  I didn't see it in 
protoc's help. google search for "protoc --go_opt" did not yield good 
results.  It did find: https://grpc.io/docs/languages/go/quickstart/, but 
I'd like to bookmark the definite list if you know where i can find it.

Cheers and thanks so much!

  
On Wednesday, July 22, 2020 at 3:17:09 PM UTC-7, Matthew Walster wrote:
>
> John,
>
> On Wed, 22 Jul 2020 at 23:02, John > 
> wrote:
>
>> I then enter that directory and do:
>>
>> /usr/local/bin/protoc -I =./ ./name.proto --go_out=plugins=grpc:./ 
>> --proto_path=/home/user/go/src
>>
>> This works, however it doesn't generate the go files in that directory, 
>> it generates it inside the proto's directory with a directory structure 
>> like:
>>
>
> Have you tried using an option like: --go_opt=paths=source_relative
>
> Matthew Walster
>

-- 
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/71f0cd9b-6197-4c1e-94fa-a41df7f8cdeco%40googlegroups.com.

[go-nuts] What should be a silly protoc golang question

[John]

In essence, I'm switching over to the new go protocol buffer lib and protoc 
libraries.

In the new version, you are told to specify go_package option in the .proto 
file.  So I updated all mine to have that:

 go_package = "path/to/my/proto";


I use a script that finds all my proto files and the generates the go files 
by recursively moving through folders looking for .proto files.

I then enter that directory and do:

/usr/local/bin/protoc -I =./ ./name.proto --go_out=plugins=grpc:./ 
--proto_path=/home/user/go/src

This works, however it doesn't generate the go files in that directory, it 
generates it inside the proto's directory with a directory structure like:

./path/to/my/proto/name.pb.go

Where, what I want is: 

name.pb.go

I've tired a bunch of different options, nothing seems to get me what I 
want.  

Anyone know where I'm going wrong here?

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/ad5c5812-37e3-4f84-bd1d-5fcfcc9cb28eo%40googlegroups.com.

[go-nuts] New tool and vscode extension to optimize your structures: cpu cache alignment, memory packing, false sharing guarding, and more.

[John Brown]

Hello gophers, recently I published go tool and extension for vscode to 
help with some common performance transformations for structs, such as:

   - 
   
   cpu cache alignment
   - 
   
   memory packing
   - 
   
   false sharing guarding
   - 
   
   auto annotation
   - 
   
   generic fields management, etc.
   
It supports direct transformation of go code and other useful outputs.

Check it out the repo https://github.com/1pkg/gopium and/or extension page 
https://marketplace.visualstudio.com/items?itemName=1pkg.gopium

-- 
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/0797839f-35f3-49bf-bb1f-af541cfecce6o%40googlegroups.com.

Re: [go-nuts] Compiler error when using an interface type in a list

[John Sturdy]

Thanks --- I understand the difference now... I had expected the compiler 
to handle it, on the basis of being able to use an implementation of an 
interface type wherever the interface type is used, but it looks like it's 
a mixture of static and dynamic typing and this is where they don't quite 
join up.  I'll try the solution you suggest.

On Thursday, June 11, 2020 at 6:03:59 PM UTC+1, burak serdar wrote:
>
> On Thu, Jun 11, 2020 at 10:50 AM John Sturdy  > wrote: 
> > 
> > I've defined an interface type, and a concrete type that I think 
> implements that interface, but when I use it in a list, I get an error from 
> the compiler that makes it look like it doesn't. 
> > 
> > Here's my interface type, in anything/anything.go: 
> > 
> > package anything 
> > 
> > import ( 
> > "fmt" 
> > ) 
> > 
> > type AnyThing interface { 
> > Textual() string 
> > Numeric(name string) int 
> > } 
> > 
> > func OneCallee(thing AnyThing) { 
> > fmt.Printf("textual result is %s and numeric result is 
> %d\n", thing.Textual(), thing.Numeric("default")) 
> > } 
> > 
> > func ListCallee(things []AnyThing) { 
> > fmt.Printf("textual result is %s and numeric result is 
> %d\n", things[0].Textual(), things[0].Numeric("default")) 
> > } 
> > 
> > 
> > and here's a concrete type that defines the methods required by the 
> interface, in particularthing/particularthing.go: 
> > 
> > package particularthing 
> > 
> > type ParticularThing struct { 
> > Name string 
> > Number int 
> > } 
> > 
> > func (n ParticularThing) Textual() string { 
> > return n.Name 
> > } 
> > 
> > func (n ParticularThing) Numeric(name string) int { 
> > return n.Number 
> > } 
> > 
> > and here's the caller: 
> > 
> > package main 
> > 
> > import ( 
> > "example.com/user/scratch/anything" 
> > "example.com/user/scratch/particularthing" 
> > ) 
> > 
> > func main() { 
> > onething := particularthing.ParticularThing{"this", 1} 
> > anything.OneCallee(onething) 
> > thinglist := make([]particularthing.ParticularThing, 1) 
> > anything.ListCallee(thinglist) 
> > } 
> > 
> > When I compile it, I get: 
> > 
> > ./caller.go:12:21: cannot use thinglist (type 
> []particularthing.ParticularThing) as type []anything.AnyThing in argument 
> to anything.ListCallee 
> > 
> > Could some explain what the problem with this is? 
>
> An array of values implementing an interface cannot be used in place 
> of an array of those interfaces. Go's type system simply compares the 
> type required with the type provided, and []someInterface is not 
> []someType. Note that the structure of the two objects passed to the 
> function is quite different. The function expects a []someInterface 
> where each element of the array is a pair containing the pointer to 
> the value and the type, but you are sending []someType where each 
> element is a value. So you have to convert: 
>
> intfList:=make([]AnyThing,0) 
> for _,x:=range thingList { 
>intfList=append(intfList,x) 
> } 
> anything.ListCallee(intfList) 
>
> You can argue that the compiler can do this conversion. Such 
> potentially expensive operations are explicit in Go, which creates 
> some clutter but overall not a bad thing. 
>
>
>
> > 
> > I've attached a tarball of the files to make experimental changes 
> easier. 
> > 
> > -- 
> > 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/3abb649b-f134-4535-8832-18c8ca0a54ebo%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/a0a9700f-d3b4-4ee3-bafd-08a5cd5f5582o%40googlegroups.com.

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

[John Arundel]

On Saturday, 29 February 2020 18:11:53 UTC, Warren Stephens wrote:
>
> The influence that test code has on the structure of the application code 
> is highly undesirable. 
>

On the contrary, I think designing for testability improves your 
architecture considerably! And if you develop test-first, you never write 
untestable functions.

-- 
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/45d23743-dce3-4780-9d70-aeed1852f08c%40googlegroups.com.

[go-nuts] html/template: Unable to execute a method on non-pointer struct where method receiver is a pointer (can't evaluate field error)

[John]

[non-pointer struct]. cannot be invoked 
directly in a template.

package main

import (
"fmt"
"bytes"
"html/template"
)

type Wrapper struct {
raw []int
}

func (w *Wrapper) IsZero() bool {
if  len(w.raw) == 0{
return true
}
return false
}


var tmplText = `
{{.IsZero}}
` 

var tmpl = template.Must(template.New("test").Parse(tmplText))

func main() { 
wrapped := Wrapper{}
fmt.Println(wrapped.IsZero())

buff := {}
if err := tmpl.Execute(buff, wrapped); err != nil {
panic(err)
}

fmt.Println(buff.String())
}

Will produce: 

panic: template: test:2:3: executing "test" at <.IsZero>: can't evaluate field 
IsZero in type main.Wrapper

goroutine 1 [running]:
main.main()
/tmp/sandbox009718456/prog.go:33 +0x200



However, changing wrapped from Wrapper to a *Wrapper will work.  

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

Again this might be expected, but I found it a surprised (because I can 
clearly call the method outside the template).  In my real life case, this 
was layers deep in a structs I had to unpack and experiment with to find 
the cause.

The error wasn't clear as to why this was happening, I could not find 
documentation within template to hint at a limitation (maybe I missed it or 
I did not interpret the meaning of something correctly).

What I'm looking from this post:

   - Are my assumptions correct or is the proof above invalid
   - If the proof is valid, is this expected behavior?
   - If expected, is there documentation for this?
   - and, can we see a way to have better error output, I know this is 
   probably difficult due to trying to reflect on what is a field vs a method 
   when something can't be found

Also, trying to document the error here so it gets picked up in Google when 
looking for this error condition, as I was unable to find anything similar.

-- 
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/4f28f591-1dfc-45d3-b6ac-707734fad394%40googlegroups.com.

Re: [go-nuts] RecvMsgUDP / SendMsgUDP

[John Dreystadt]

On Monday, January 6, 2020 at 5:42:04 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Jan 6, 2020 at 12:46 PM John Dreystadt  > wrote: 
> > 
> > I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP 
> seemed a bit odd because it referred to “out of band” for some of the 
> parameters being passed and some of the return values. This caused me to 
> look closely at these two functions and here are the results of my 
> research. First, the documentation uses “out of band” when most other 
> documentation, such as the Linux docs for recvmsg(2), use either “control 
> messages” or “ancillary information” for the same fields. This may confuse 
> newcomers to these functions as “out of band” looks like a reference to the 
> TCP concept of “out of band” which is specific to TCP and not present in 
> UDP. Second, the “out of band” fields in question are not useful unless 
> certain socket options are set which cannot be done using the functions 
> available in the “net” package. Third, the “golang.org/x/net” package 
> provides access to most of the socket options in question but not all (the 
> socket option IPPROTO_IP, IP_PKTINFO is not available). There are functions 
> in “golang.org/x/net/internal/socket” for both setting arbitrary socket 
> options and calling recvmsg/sendmsg (still assuming Linux here but Windows 
> just has different names). These cannot be called by user programs because 
> they are in an “internal” package. Fourth and last, I don’t see any way to 
> determine if a read of a TCP socket (not UDP this time) has returned out of 
> band information. In C, I would use recvmsg and check the returned flags 
> for the bit MSG_OOB but there is no RecvMesgTCP. 
> > 
> > I have a proposal for changes but I wanted to see if anyone disagreed 
> with the above. I would be especially interested in anyone using these two 
> functions today. 
>
> I guess you're talking about net.UDPConn.WriteMsgUDP and 
> net.UDPConn.ReadMsgUDP.  I agree that on Unix systems that "out of 
> band" data is normally called "ancillary data," and we should change 
> the net package docs. 
>
> User programs can set arbitrary socket options by using 
> net.UDPConn.SyscallConn to get a syscall.RawConn and calling the 
> Control method.  But I agree that that procedure needs to be better 
> documented somewhere. 
>
> I'm kind of surprised that there is no way to handle TCP out-of-band 
> data but I admit that I don't see one. 
>
> Ian 
>

Sigh, sorry for getting the names wrong. Anyway, I see what Ian means about 
using the Control method to set an arbitrary socket option but I would not 
have found it without his prompting. So either we need a different 
procedure or better documentation. Which leads me into my proposal for 
changes.

Change 1, add WriteMsg and ReadMsg functions to the different socket types 
in x/net. This seems more in keeping with the division between the main net 
package and x/net. Not hard to do as the existing code for WriteMsgUDP and 
ReadMsgUDP can be used as a start. This would also fix the issue of 
handling TCP out-of-band data since TCP sockets would get the new functions.

Change 2, add GetSocketOption and SetSocketOption functions to the  same 
socket types in x/net. Again, not hard to do as these would be wrapper 
functions calling the Get and Set functions on 
x/net/internal/socket.Option. Documentation would be much easier than 
explaining how to use the syscall mechanism.

Change 3, deprecate the existing WriteMsgUDP and ReadMsgUDP functions 
pointing users to the new WriteMsg and ReadMsg functions. 

Any comments?

John Dreystadt

-- 
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/20540f17-67b7-4e53-8dea-b059996f99d2%40googlegroups.com.

[go-nuts] RecvMsgUDP / SendMsgUDP

[John Dreystadt]

I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP seemed 
a bit odd because it referred to “out of band” for some of the parameters being 
passed and some of the return values. This caused me to look closely at these 
two functions and here are the results of my research. First, the documentation 
uses “out of band” when most other documentation, such as the Linux docs for 
recvmsg(2), use either “control messages” or “ancillary information” for the 
same fields. This may confuse newcomers to these functions as “out of band” 
looks like a reference to the TCP concept of “out of band” which is specific to 
TCP and not present in UDP. Second, the “out of band” fields in question are 
not useful unless certain socket options are set which cannot be done using the 
functions available in the “net” package. Third, the “golang.org/x/net” package 
provides access to most of the socket options in question but not all (the 
socket option IPPROTO_IP, IP_PKTINFO is not available). There are functions in 
“golang.org/x/net/internal/socket” for both setting arbitrary socket options 
and calling recvmsg/sendmsg (still assuming Linux here but Windows just has 
different names). These cannot be called by user programs because they are in 
an “internal” package. Fourth and last, I don’t see any way to determine if a 
read of a TCP socket (not UDP this time) has returned out of band information. 
In C, I would use recvmsg and check the returned flags for the bit MSG_OOB but 
there is no RecvMesgTCP.

I have a proposal for changes but I wanted to see if anyone disagreed with the 
above. I would be especially interested in anyone using these two functions 
today.

John Dreystadt 
 

-- 
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/5fce6cc7-8129-42a2-ade7-26c8b2d609f7%40googlegroups.com.

Re: [go-nuts] Re: Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

[John]

Hey Michel,

In that example, it is indeed the reference to the Payload that causes it 
not to go out of scope.  But you can't print it with the function parameter 
o, because that is not the slice itself, but the pointer to the first byte 
of the slice.
I would either need a runtime call that removed the local reference, the 
oppositoe of KeepAlive() or there might be some way of using Unsafe on this 
to walk the array C style, but that just seems like a bad idea.



On Tuesday, December 31, 2019 at 2:53:26 AM UTC-8, Michel Levieux wrote:
>
> Hi John,
>
> I'm not sure what I'm about to say (i can't test anything right now), but 
> in your last example, wouldn't it be that the finalizer is never called 
> because the function you give it is a closure that holds a reference of 
> b.Payload itself? Thus the GC would consider b.Payload never unreachable 
> and never call its finalizer? Have you tried doing the same thing (print 
> the finalized object) using the function parameter o, rather than an object 
> of the surrounding scope?
>
> Hope this helps
>
> Le lun. 30 déc. 2019 à 17:31, John > a 
> écrit :
>
>> Thank you Keith, that is a very interesting technique, I doubt I would 
>> have come up with that.
>>
>> Unfortunately, that lead me to another problem as I needed the finalizer 
>> to have access to the entire underlying data, which I did not state when I 
>> wrote my question.
>>
>> I tried to extend this to provide the whole slice to the finalizer using 
>> the current scope:
>>
>> type Blah struct {
>> Payload []byte
>> }
>>
>> func do() {
>> b := {Payload: make([]byte, 100)}
>> runtime.SetFinalizer([0], func(o 
>> *byte){log.Println("finalized"); fmt.Println("b.Payload[1] })
>> ...
>> }
>>
>> That of course created a reference to the slice in the finalizer, which 
>> then prevents the slice from being GC'd, defeating the purpose.
>>
>> The more I've dug into this, the more I can see that trying to do this is 
>> probably not possible, or at best, never going to be safe.  It was a nice 
>> thought experiment though.
>>
>> Thanks for the help Keith.  
>>
>> On Sunday, December 29, 2019 at 9:16:53 PM UTC-8, Keith Randall wrote:
>>>
>>> It should work to just set the finalizer on the first byte of an 
>>> allocation. i.e.:
>>>
>>> s := make([]byte, N)
>>> runtime.SetFinalizer([0], func(b *byte) { ... })
>>>
>>> Note that the spec of runtime.SetFinalizer doesn't actually guarantee 
>>> that this will work. But I think in the current implementation it will.
>>>
>>> > The argument obj must be a pointer to an object allocated by calling 
>>> new, by taking the address of a composite literal, or by taking the address 
>>> of a local variable.
>>>
>>> The result of make isn't "an object created by calling new", but it it 
>>> close.
>>>
>>> On Saturday, December 28, 2019 at 9:27:29 PM UTC-8, John wrote:
>>>>
>>>> Looking for a little insight on if it is possible to do something:
>>>>
>>>> Given this type:
>>>>
>>>> type Blah struct {
>>>> Payload []byte
>>>> }
>>>>
>>>> What I'm looking for is to kick off a finalizer when a slice and all 
>>>> other slices backed by the same array get GC'd. 
>>>>
>>>> In lieu of that, whenver the pointer to the array backing a slice get's 
>>>> GC'd. I realize that in this case, the slice actually may stay around when 
>>>> the array is GC'd because an append creates a new array on the slice.
>>>>
>>>> I don't think the first is possible, as you can't call SetFinalizer() 
>>>> on non-pointer types. And I can't use any wrappers or pointers to []byte 
>>>> in 
>>>> lieu of []byte for my use case.
>>>>
>>>> I figure there is a way to use:
>>>>
>>>> hdr := (*reflect.SliceHeader)(unsafe.Pointer())
>>>>
>>>> to set a finalizer on the underlying arrray.
>>>>
>>>> But I'm not sure exactly how to convert the hdr.Data into the specific 
>>>> array type pointer to use in SetFinalizer().  It may not be possible.
>>>>
>>>> To save some time on a few questions:  I'm aware of the flaws of 
>>>> SetFinalizer(), just looking to see if this can actually be done.
>>>>
>>>> Thanks for any help.
>>>>
>>> -- 
>&

[go-nuts] Re: Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

[John]

Thank you Keith, that is a very interesting technique, I doubt I would have 
come up with that.

Unfortunately, that lead me to another problem as I needed the finalizer to 
have access to the entire underlying data, which I did not state when I 
wrote my question.

I tried to extend this to provide the whole slice to the finalizer using 
the current scope:

type Blah struct {
Payload []byte
}

func do() {
b := {Payload: make([]byte, 100)}
runtime.SetFinalizer([0], func(o 
*byte){log.Println("finalized"); fmt.Println("b.Payload[1] })
...
}

That of course created a reference to the slice in the finalizer, which 
then prevents the slice from being GC'd, defeating the purpose.

The more I've dug into this, the more I can see that trying to do this is 
probably not possible, or at best, never going to be safe.  It was a nice 
thought experiment though.

Thanks for the help Keith.  

On Sunday, December 29, 2019 at 9:16:53 PM UTC-8, Keith Randall wrote:
>
> It should work to just set the finalizer on the first byte of an 
> allocation. i.e.:
>
> s := make([]byte, N)
> runtime.SetFinalizer([0], func(b *byte) { ... })
>
> Note that the spec of runtime.SetFinalizer doesn't actually guarantee that 
> this will work. But I think in the current implementation it will.
>
> > The argument obj must be a pointer to an object allocated by calling 
> new, by taking the address of a composite literal, or by taking the address 
> of a local variable.
>
> The result of make isn't "an object created by calling new", but it it 
> close.
>
> On Saturday, December 28, 2019 at 9:27:29 PM UTC-8, John wrote:
>>
>> Looking for a little insight on if it is possible to do something:
>>
>> Given this type:
>>
>> type Blah struct {
>> Payload []byte
>> }
>>
>> What I'm looking for is to kick off a finalizer when a slice and all 
>> other slices backed by the same array get GC'd. 
>>
>> In lieu of that, whenver the pointer to the array backing a slice get's 
>> GC'd. I realize that in this case, the slice actually may stay around when 
>> the array is GC'd because an append creates a new array on the slice.
>>
>> I don't think the first is possible, as you can't call SetFinalizer() on 
>> non-pointer types. And I can't use any wrappers or pointers to []byte in 
>> lieu of []byte for my use case.
>>
>> I figure there is a way to use:
>>
>> hdr := (*reflect.SliceHeader)(unsafe.Pointer())
>>
>> to set a finalizer on the underlying arrray.
>>
>> But I'm not sure exactly how to convert the hdr.Data into the specific 
>> array type pointer to use in SetFinalizer().  It may not be possible.
>>
>> To save some time on a few questions:  I'm aware of the flaws of 
>> SetFinalizer(), just looking to see if this can actually be done.
>>
>> Thanks for any help.
>>
>

-- 
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/fb37ba35-9104-4278-96f3-92045a4ddb45%40googlegroups.com.

[go-nuts] Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

[John]

Looking for a little insight on if it is possible to do something:

Given this type:

type Blah struct {
Payload []byte
}

What I'm looking for is to kick off a finalizer when a slice and all other 
slices backed by the same array get GC'd. 

In lieu of that, whenver the pointer to the array backing a slice get's 
GC'd. I realize that in this case, the slice actually may stay around when 
the array is GC'd because an append creates a new array on the slice.

I don't think the first is possible, as you can't call SetFinalizer() on 
non-pointer types. And I can't use any wrappers or pointers to []byte in 
lieu of []byte for my use case.

I figure there is a way to use:

hdr := (*reflect.SliceHeader)(unsafe.Pointer())

to set a finalizer on the underlying arrray.

But I'm not sure exactly how to convert the hdr.Data into the specific 
array type pointer to use in SetFinalizer().  It may not be possible.

To save some time on a few questions:  I'm aware of the flaws of 
SetFinalizer(), just looking to see if this can actually be done.

Thanks for any help.

-- 
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/51f0f8db-4f08-4386-87be-48d884a0edb5%40googlegroups.com.

[go-nuts] Re: Scheduling - find the overlap size of two sequential date ranges and determine the actual dates of included in the intersection

[John More]

Updated playground code
https://play.golang.org/p/qHufIG5ppww

On Sunday, June 16, 2019 at 12:48:25 PM UTC-4, John More wrote:
>
> I have created a program to solve this problem (
> https://play.golang.org/p/BueQBahUUbk) but I am not a pro and do not know 
> if there is a better way. 
>
> Thanks for your time and a huge than You to Yudai the creator of "
> github.com/yudai/golcs" . I have also attached the code.
>
>
>

-- 
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/b36994da-2de1-420e-a15f-b62c0456f879%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Scheduling - find the overlap size of two sequential date ranges and determine the actual dates of included in the intersection

[John More]

I have created a program to solve this problem 
(https://play.golang.org/p/BueQBahUUbk) but I am not a pro and do not know 
if there is a better way. 

Thanks for your time and a huge than You to Yudai the creator of 
"github.com/yudai/golcs" . I have also attached the code.


-- 
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/90f40950-746d-48db-a7b1-992e54bd3762%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Should IP.DefaultMask() exist in today's Internet?

[John Dreystadt]

>> 
>> 
>>> On Thursday, 2 May 2019 14:09:09 UTC+2, Louki Sumirniy wrote:
>>> The function has a very specific purpose that I have encountered in several 
>>> applications, that being to automatically set the netmask based on the IP 
>>> being one of the several defined ones, 192, 10, and i forget which others. 
>>> 
>>> Incorrect netmask can result in not recognising a LAN address that is 
>>> incorrect. A 192.168 network has 255 available addresses. You can't just 
>>> presume to make a new 192.168.X... address with a /16, as no other 
>>> correctly configured node in the LAN will be able to route to it due to it 
>>> being a /16. 
>>> 
>>> If you consider the example of an elastic cloud type network environment, 
>>> it is important that all nodes agree on netmask or they will become 
>>> (partially) disconnected from each other. An app can be spun up for a few 
>>> seconds and grab a new address from the range, this could be done with a 
>>> broker (eg dhcp), but especially with cloud, one could use a /8 address 
>>> range and randomly select out of the 16 million possible, a big enough 
>>> space that random generally won't cause a collision - which is a cheaper 
>>> allocation procedure than a list managing broker, and would be more suited 
>>> to the dynamic cloud environment.
>>> 
>>> This function allows this type of client-side decisionmaking that a broker 
>>> bottlenecks into a service, creating an extra startup latency cost. A 
>>> randomly generated IP address takes far less time than sending a request to 
>>> a centralised broker and receiving it.
>>> 
>>> That's just one example I can think of where a pre-made list of netmasks is 
>>> useful, I'm sure more experienced network programmers can rattle off a 
>>> laundry list.
>>> 

While I kind of see your point, it still seems odd that you want a function for 
this that is in the main net package. I would expect most if not all 
applications doing dynamic assignment to pick one address range and then use a 
fixed netmask. I just think that very few programmers will need such a function 
so I don’t think Go, with its emphasis on simplicity, so have it. 
> -- 
> 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.

Re: [go-nuts] the Dominance of English in Programming Languages

[John McKown]

The solution is simple. Just program in APL. Then _nobody_ can understand
your program and so it is "fair" to all. It is a "write only" language.

https://en.wikipedia.org/wiki/APL_(programming_language)

Game of Life[edit
<https://en.wikipedia.org/w/index.php?title=APL_(programming_language)=edit=22>
]

The following function "life", written in Dyalog APL, takes a boolean
matrix and calculates the new generation according to Conway's Game of Life
<https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life>. It demonstrates
the power of APL to implement a complex algorithm in very little code, but
it is also very hard to follow unless one has advanced knowledge of APL.
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


Maranatha! <><
John McKown

-- 
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: Some issues with UDP and Go

[John Dreystadt]

Sorry it took so long for this post, other things intervened. Anyway, quick 
responses to the three people who commented.

Shulhan, there is a better mechanism in Go than resetting the buffer. Have 
a second variable, say "var message []byte", and then after the call to 
ReadMsgUDP add this line "message = buffer(:n)" and the program can use 
message without the cost of any type of reset on the buffer. The oobbuffer 
is different in that it may be used as input and should be reset as you 
say. But most applications should just past nil and ignore it.

Pelle Johansson, I think this name confusion is more than a bit 
unfortunate. But better documentation should help.

Robert Engels, you are right (as was Pelle) that UDP does not support OOB. 
But the oobbuffer and oobn are not (really, not kidding) about OOB. They 
are instead about what both the Linux and Microsoft documentation call the 
control buffer. That buffer is sometimes used to pass things along with the 
message for some protocols but I have not found a case where UDP uses that 
(still looking). It is also used to get additional information about the 
received message. The one case I have seen documented that I want to 
experiment with is when a machine has multiple interfaces and the UDP 
packet could have arrived on different ones. Then if you have set the right 
thing in the socket, you should get information about the interface in 
oobbuffer. And if oobbuffer is too short, MSG_CTRUNC should be set in the 
flags return. My short term goal is to see if I can get this working and 
then use what I find to suggest better documentation. 

-- 
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: Some issues with UDP and Go

[John Dreystadt]

Thanks, that makes sense. So the documentation here needs some work since 
that is not at all clear. 

On Sunday, April 7, 2019 at 11:42:52 AM UTC-4, Pelle Johansson wrote:
>
> Hi John,
>
> The oob data used in these system calls are not for communicating with the 
> peer. UDP doesn't support OOB data on the wire, I think the name here is a 
> bit unfortunate, it should rather be called "control" or somesuch. This 
> data is processed/created locally by the kernel and its structure is 
> probably OS specific. On Linux see the ip(7) man page for information about 
> how it can be used (search for control).
>
> Regards,
> -- 
> Per Johansson
>
> On Saturday, April 6, 2019 at 11:24:04 PM UTC+2, John Dreystadt wrote:
>>
>> I wrote some sample code (at the end of this message) to see how UDP 
>> worked in the Go environment. And I wound up with some issues because 
>> things did not seem to work as I expected. I am running go1.11.2 on both a 
>> Windows box and a Ubuntu box.
>>
>> Issue 1, when I call WriteMsgUDP with both a regular buffer and an out of 
>> band buffer, I get back the length as I expected. But I never see any out 
>> of band data on the read side. Is this a known error or am I just missing 
>> something?
>>
>> Issue 2, when I send a UDP message longer than the buffer at the 
>> receiving end I get an error on the Windows side along with a bit set in 
>> flags. The Ubuntu side does not report an error but does set a bit (but a 
>> different one). Even more odd, the Windows side does not return the address 
>> of the sending machine when this error occurs. While having one report an 
>> error while not the other is not unreasonable, losing the address of the 
>> sending machine seems really bad unless it just is not there on Windows.
>>
>> Issue 3, the documentation for the flags return from ReadMsgUDP just says 
>> "the flags set on the message" which is pretty short and does not even 
>> indicate who set the flags. Maybe something like "the flags are set on the 
>> message by the network stack and are operating system dependent".
>>
>> I used two copies of the following program running to see the issues. To 
>> replicate, first run one without any flags and then run the second with 
>> -mode=wr . 
>>
>> package main
>>
>> import (
>> "errors"
>> "flag"
>> "fmt"
>> "net"
>> )
>>
>> var rfserver = flag.String("RFS", "127.0.0.1:6000", "Read First Server 
>> Name:Port Number")
>> var wfserver = flag.String("WFS", "127.0.0.1:6001", "Write First Server 
>> Name:Port Number")
>>
>> type modeValue string
>>
>> func (mode *modeValue) String() string {
>> return string(*mode)
>> }
>>
>> func (mode *modeValue) Set(s string) error {
>> switch s {
>> case "rw":
>> *mode = modeValue(s)
>> return nil
>> case "wr":
>> *mode = modeValue(s)
>> return nil
>> default:
>> return errors.New("Mode must be rw or wr")
>> }
>> }
>>
>> var mode modeValue
>>
>> func main() {
>> mode = modeValue("rw")
>> flag.Var(, "mode", "rw for read then write and wr for the reverse")
>> flag.Parse()
>> fmt.Println("Parameters", *rfserver, *wfserver, mode)
>>
>> rfudpaddr, err := net.ResolveUDPAddr("udp", *rfserver)
>> if err != nil {
>> panic(err)
>> }
>> wfudpaddr, err := net.ResolveUDPAddr("udp", *wfserver)
>> if err != nil {
>> panic(err)
>> }
>> var rudpaddr, wudpaddr *net.UDPAddr
>> if mode == "rw" {
>> rudpaddr, wudpaddr = rfudpaddr, wfudpaddr
>> } else {
>> wudpaddr, rudpaddr = rfudpaddr, wfudpaddr
>> }
>> pc, err := net.ListenUDP("udp", rudpaddr)
>> if err != nil {
>> panic(err)
>> }
>>
>> if mode == "rw" {
>> buffer := make([]byte, 5)
>> oobbuffer := make([]byte, 5)
>> n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer)
>> fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
>> n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
>> fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
>> n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
>> fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
>> }
>>
>> n, oobn, err := pc.WriteMsgUDP([]byte("1234"

[go-nuts] Some issues with UDP and Go

[John Dreystadt]

I wrote some sample code (at the end of this message) to see how UDP worked 
in the Go environment. And I wound up with some issues because things did 
not seem to work as I expected. I am running go1.11.2 on both a Windows box 
and a Ubuntu box.

Issue 1, when I call WriteMsgUDP with both a regular buffer and an out of 
band buffer, I get back the length as I expected. But I never see any out 
of band data on the read side. Is this a known error or am I just missing 
something?

Issue 2, when I send a UDP message longer than the buffer at the receiving 
end I get an error on the Windows side along with a bit set in flags. The 
Ubuntu side does not report an error but does set a bit (but a different 
one). Even more odd, the Windows side does not return the address of the 
sending machine when this error occurs. While having one report an error 
while not the other is not unreasonable, losing the address of the sending 
machine seems really bad unless it just is not there on Windows.

Issue 3, the documentation for the flags return from ReadMsgUDP just says 
"the flags set on the message" which is pretty short and does not even 
indicate who set the flags. Maybe something like "the flags are set on the 
message by the network stack and are operating system dependent".

I used two copies of the following program running to see the issues. To 
replicate, first run one without any flags and then run the second with 
-mode=wr . 

package main

import (
"errors"
"flag"
"fmt"
"net"
)

var rfserver = flag.String("RFS", "127.0.0.1:6000", "Read First Server 
Name:Port Number")
var wfserver = flag.String("WFS", "127.0.0.1:6001", "Write First Server 
Name:Port Number")

type modeValue string

func (mode *modeValue) String() string {
return string(*mode)
}

func (mode *modeValue) Set(s string) error {
switch s {
case "rw":
*mode = modeValue(s)
return nil
case "wr":
*mode = modeValue(s)
return nil
default:
return errors.New("Mode must be rw or wr")
}
}

var mode modeValue

func main() {
mode = modeValue("rw")
flag.Var(, "mode", "rw for read then write and wr for the reverse")
flag.Parse()
fmt.Println("Parameters", *rfserver, *wfserver, mode)

rfudpaddr, err := net.ResolveUDPAddr("udp", *rfserver)
if err != nil {
panic(err)
}
wfudpaddr, err := net.ResolveUDPAddr("udp", *wfserver)
if err != nil {
panic(err)
}
var rudpaddr, wudpaddr *net.UDPAddr
if mode == "rw" {
rudpaddr, wudpaddr = rfudpaddr, wfudpaddr
} else {
wudpaddr, rudpaddr = rfudpaddr, wfudpaddr
}
pc, err := net.ListenUDP("udp", rudpaddr)
if err != nil {
panic(err)
}

if mode == "rw" {
buffer := make([]byte, 5)
oobbuffer := make([]byte, 5)
n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
}

n, oobn, err := pc.WriteMsgUDP([]byte("1234"), []byte("1"), wudpaddr)
fmt.Println("n, oobn, err", n, oobn, err)
n, oobn, err = pc.WriteMsgUDP([]byte("12345"), nil, wudpaddr)
fmt.Println("n, err", n, oobn, err)
n, oobn, err = pc.WriteMsgUDP([]byte("123456"), nil, wudpaddr)
fmt.Println("n, err", n, oobn, err)

if mode == "wr" {
buffer := make([]byte, 5)
oobbuffer := make([]byte, 5)
n, oobn, flags, addr, err := pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
n, oobn, flags, addr, err = pc.ReadMsgUDP(buffer, oobbuffer)
fmt.Println("n,oobn,flags,addr,err", n, oobn, flags, addr, err)
}

}

-- 
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: Should IP.DefaultMask() exist in today's Internet?

[John Dreystadt]

Yes, I was mistaken on this point. I got confused over someone's discussion 
of RFC 1918 with what the standard actually said. I should have checked 
closer before I posted that point. But I still don't see the reason for 
this function. In today's networking, the actual value you should use for a 
mask on an interface on the public Internet is decided by a combination of 
the address range you have and how it is divided by your local networking 
people. On the private networks, it is entirely up to the local networking 
people. The value returned by this function is only a guess, and I think it 
is more likely to mislead than to inform.

On Friday, March 8, 2019 at 12:51:41 PM UTC-5, Tristan Colgate wrote:
>
> Just on a point of clarity. DefaultMask is returning the mask associates 
> with the network class. RFC1918 specifies a bunch of class A,B and C 
> networks for private use. E.g. 192.168/16 is a set of 256 class C networks. 
> The correct netmask for one of those class Cs is 255.255.255.0 (/24). So 
> the function returns the correct thing by the RFC.
>   
>
>
>>
>>

-- 
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: Should IP.DefaultMask() exist in today's Internet?

[John Dreystadt]

Just to be sure we are saying the same things, I am saying that the 
programmer should be getting the interfaces for the network and walking 
them looking for the interface with the address they are interested in, and 
getting the IPMask for that interface. Alas, this is harder than it might 
be, you have to use a type switch to get the mask since what the 
net.Interfaces() gives you is a *net.Addr while the mask is part of the 
implementation, *net.IPNet. As it stands, a new programmer might think 
DefaultMask() is what should be called.

On Thursday, March 7, 2019 at 7:49:20 PM UTC-5, Ian Lance Taylor wrote:
>
> On Thu, Mar 7, 2019 at 2:42 PM John Dreystadt  > wrote: 
> > 
> > I have not seen any response to my last posting yet, and I think it is 
> still an open question. I also realized an additional point that I should 
> have pointed out before which is that this is an IPv4 only thing. Which 
> means that I really don't understand when you would use this function. 
> Would it make sense to poll the golang-nuts community to see who is using 
> this call and what for? Other than to determine if an address is IPv4, when 
> To4() should be used instead. 
>
> I think you are basically recommending that we add a sentence to the 
> DefaultMask method docs saying that you should probably be using an 
> IPMask?  That sounds reasonable to me. 
>
> 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: Should IP.DefaultMask() exist in today's Internet?

[John Dreystadt]

I have not seen any response to my last posting yet, and I think it is 
still an open question. I also realized an additional point that I should 
have pointed out before which is that this is an IPv4 only thing. Which 
means that I really don't understand when you would use this function. 
Would it make sense to poll the golang-nuts community to see who is using 
this call and what for? Other than to determine if an address is IPv4, when 
To4() should be used instead.

>
>

-- 
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] Different Languages of a Program Project

[John]

I have come to a realization about programming and the different roles of 
each language in a project. Here below are what I thought, and hope that I 
may receive confirmation from my fellow programmers. Thank you.

Golang: Main Project Management
HTML: Website Formatting
Javascript: Creating Animations etc.
HTTP: Web Page Management

-- 
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: Should IP.DefaultMask() exist in today's Internet?

[John Dreystadt]

Looking at RFC 1918 (which defined the non-routeable address ranges), it 
says that 10.0.0.0 has a 10/8 prefix which matches what DefaultMask() 
returns as a mask. But 192.168.0.0 returns FF00 while the RFC says that 
it should have a 192.168/16 prefix () . And 17.16.0.0 returns 
 while the RFC says that it should have a 17.16/12 prefix 
(FFF0). I also don't see the use case for this function. If this is an 
IP address associated with the current machine, the code should be walking 
the net interfaces and getting the mask from the OS. If this is an IP 
address associated with some other machine, why do you need an IP mask? In 
all of my years programming on the Internet, I never needed to know the 
mask of a remote machine.  

On Saturday, March 2, 2019 at 6:07:22 PM UTC-5, Louki Sumirniy wrote:
>
> The function is really just looking up the IP prefixes of the 
> non-routeable address ranges. It has nothing to do with CIDR, it is for 
> generating a sane default mask when the user has not specified the mask.
>
> It most definitely should not be deprecated, as these nonrouteable 
> addresses are definitely not deprecated, and CIDR is an extension, not a 
> replacement, for IPv4 subnet specification, to give administrators more 
> flexibliity when configuring multiple address ranges in a fairly large 
> intranet.
>
> On Saturday, 2 March 2019 22:32:28 UTC+1, John Dreystadt wrote:
>>
>> I am new to Go so feel free to point out if I am breaking protocol but I 
>> ran into the function DefaultMask() in the net package and did some 
>> research. This function returns the IPMask by assuming that you are using 
>> IP class A, B, and C addresses. But this concept is from the early days of 
>> the Internet, and was superseded by CIDR in 1993. See 
>> https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing for the 
>> history here. I looked around both this group and on Stack Overflow to see 
>> what people had posted about this function. The only reference in 
>> golang-nuts was to someone using this call to decide if an address was IPv4 
>> or not. As the last posting on that thread pointed out, you can use To4() 
>> for the same purpose (since DefaultMask actually calls To4). The only 
>> reference on Stack Overflow was someone using it to get the "Next IP 
>> address". Sorry but I don't understand what he was doing. If you want the 
>> IPMask for 127.0.0.1, you can just get that interface and get the mask that 
>> way. I even tried Google for "golang DefaultMask" and only found hits about 
>> non network things. So I don't believe that this function is useful today 
>> and should be deprecated, maybe with a message about using To4() if you 
>> just want to see if an address is IPv4.
>>
>

-- 
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] Should IP.DefaultMask() exist in today's Internet?

[John Dreystadt]

I am new to Go so feel free to point out if I am breaking protocol but I 
ran into the function DefaultMask() in the net package and did some 
research. This function returns the IPMask by assuming that you are using 
IP class A, B, and C addresses. But this concept is from the early days of 
the Internet, and was superseded by CIDR in 1993. 
See https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing for the 
history here. I looked around both this group and on Stack Overflow to see 
what people had posted about this function. The only reference in 
golang-nuts was to someone using this call to decide if an address was IPv4 
or not. As the last posting on that thread pointed out, you can use To4() 
for the same purpose (since DefaultMask actually calls To4). The only 
reference on Stack Overflow was someone using it to get the "Next IP 
address". Sorry but I don't understand what he was doing. If you want the 
IPMask for 127.0.0.1, you can just get that interface and get the mask that 
way. I even tried Google for "golang DefaultMask" and only found hits about 
non network things. So I don't believe that this function is useful today 
and should be deprecated, maybe with a message about using To4() if you 
just want to see if an address is IPv4.

-- 
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: Question for "net" package experts

[John Dreystadt]

Ah, thanks. Now I understand, the need was to distinguish the value. I 
wonder if there might be some way to document this a bit better. Not a high 
priority but I will see if I can come up with anything.

-- 
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: Question for "net" package experts

[John Dreystadt]

The docs state “Network returns the address's network name, "ip+net".” which is 
accurate but not really an answer. I was asking if there is some meaning for 
this value. If it was just “ip” this would actually make more sense to me 
because it would indicate that TCP and  UDP were both supported, either IPv6 or 
IPv4. But what is the “+net” addition trying to tell me?

-- 
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 for "net" package experts

[John Dreystadt]

The Network function of the various Addr types in the "net" package 
sometimes returns the string "net+ip". I don't see any description of this 
value and the my best guess is that it is saying that the address is an IP 
network address (from the ip) and it is a network address (from the net) 
but the second seems redundant and makes the return value difficult to use. 
I assume I am missing something but what? Thanks in advance.

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

[go-nuts] Re: Missing well-known IPv4 address

[John Dreystadt]

Sigh, I see your point. One of those ugly issues where the standard allows 
a whole range of values but in reality people only ever use one specific 
value. But you don't want to hard code something because of the standard. 

-- 
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] Missing well-known IPv4 address

[John Dreystadt]

The well known IPv4 addresses defined in ip.go do not include an entry for 
the loopback address but the IPv6 addresses does have this entry. I propose 
that IPv4loopback with a value of IPv4(127, 0, 0, 1) be added to ip.go. 
This is not a big issue but it looks inconsistent as it stands.

-- 
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] Diagnose

[John]

Dear Gophers,
 I have made a connect five game, and am planning to make it a website. But 
first, there is a diagnostic problem. My win function depends on if a 
points neighbouring 4 dots  ..x.. are all the same type. But if its on the 
edge it will not run, as it only has 2 neighbours X .. I made this 
function, but it still wont work, also if there is a way to shorten it I 
will be glad to use it..:
func simple() {
if x == "1"|| x == "2"|| x == "3"|| x == "4"|| x == "5"|| x == "6"|| x == 
"7"|| x == "8"|| x == "9"|| x == "10"|| x == "11"|| x == "12"|| x == "13"|| 
x == "14"|| x == "15" {
if y == "1"|| y == "2"|| y == "3"|| y == "4"|| y == "5"|| y == "6"|| y == 
"7"|| y == "8"|| y == "9"|| y == "10"|| y == "11"|| y == "12"|| y == "13"|| 
y == "14"|| y == "15" {
wiwi()
} else {
showBoard()
fmt.Println("Sorry you had entered wrong please enter again")
fmt.Scanln(,)
simple()
}
}
}
 Ps it is before the win function in the game function.




 John

-- 
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] This Makes No Sense

[John]

Dear Gophers,

I have recently made a project of Connect Five. When the imput is wrong it 
will have a goroutine problem that says something about out of index, as my 
game win function depends on if the x = b and x+1 = b and so on. But if the 
imput is not 1,2 1,3 and so on, or it is over 15, 15 it will be wrong. I 
made a solution of creating a function like this: 

func fix() {
if x == "1"|| x == "2"|| x == "3"|| x == "4"|| x == "5"|| x == "6"|| x == 
"7"|| x == "8"|| x == "9"|| x == "10"|| x == "11"|| x == "12"|| x == "13"|| 
x == "14"|| x == "15" {
if y == "1"|| y == "2"|| y == "3"|| y == "4"|| y == "5"|| y == "6"|| y == 
"7"|| y == "8"|| y == "9"|| y == "10"|| y == "11"|| y == "12"|| y == "13"|| 
y == "14"|| y == "15" {
blwi()
}  else {
showBoard()
fmt.Println("Sorry you had entered wrong please enter again")
fmt.Scanln(,)
fix()
}
}

It for some reason won't work. So I wonder if any of you can help me 
correct the function and simplify it. (it goes right between the imput and 
the win function.)
  
 

-- 
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] Arrays

[John]

Dear Gophers,

  I am a beginner gopher has created a project of Connect Five. The 
game's board is shown in a dot array like this

...
...
...
 And to input, you have to put in the exact coordinates of the place 
you want to place, like this 1 3. You would have to carefully count the 
dots and then input, which is a pain for the eyes. So I wonder if it is 
possible to make a array like this and how:
 

11 12 13 14
21 22 23 24
31 32 33 34



 Thank you,



   John

-- 
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: Channels: selecting the last element

[Halderman, John]

You are both correct, I somehow missed that they were buffered. Thanks for
correcting me. On a side note, is there a reason not to use a wait all?
Thanks.

On Tue, Dec 18, 2018 at 10:05 AM Robert Engels 
wrote:

> I don’t think that code is correct. You are using buffered channels do it
> could read the done values and exit before reading any results technically
> since when data is available on both it is random which is read.
>
> On Dec 18, 2018, at 8:32 AM, john_halder...@moma.org wrote:
>
> This code works though, it's not possible to send the dc before the rc is
> read and so the done counter cannot reach 2 before both 0s have been
> written. I made a playground that runs it 100k times to demonstrate.
> https://play.golang.org/p/DKltfzDI95L
>
> On Tuesday, December 18, 2018 at 8:35:26 AM UTC-5, Chris Burkert wrote:
>>
>> Dear all,
>>
>> I have a couple of goroutines sending multiple results over a channel - a
>> simple fan-in. They signal the completion on a done channel. Main selects
>> on the results and done channel in parallel. As the select is random main
>> sometimes misses to select the last result. What would be the idiomatic way
>> to prevent this and completely drain the result channel?
>>
>> Here is a minmal example which sometimes prints one 0 but should always
>> print two of them:
>>
>> package main
>>
>> import (
>> "fmt"
>> )
>>
>> func do(rc chan<- int, dc chan<- bool) {
>> rc <- 0
>> dc <- true
>> }
>>
>> func main() {
>> worker := 2
>> rc := make(chan int, worker)
>> done := 0
>> dc := make(chan bool, worker)
>> for i := 0; i < worker; i++ {
>> go do(rc, dc)
>> }
>> for done < worker {
>> select {
>> case <-dc:
>> done++
>> case r := <-rc:
>> fmt.Println(r)
>> }
>> }
>> }
>>
>> many thanks
>> Chris
>>
> --
> 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.

Re: [go-nuts] Calendar Integration Values

[John More]

Thank You.
I was afraid that would be the answer, but my research could not match 
yours. 
I will keep looking; however there does have to be a better way to provide 
API access to outside resources without involving my domain users . I 
always use a service account with DWD enabled and use my admin account to 
access calendars in my domain. 

Thanks
John

On Tuesday, October 23, 2018 at 8:24:36 PM UTC-4, mingle wrote:
>
> John,
>
> Here's what I found.  I believe this private URL includes what Google 
> refers to as a "magic cookie" for authentication.
>
> An old post (from 2008) asks if this can be retrieved via an API, with a 
> response from Google:
>
> https://markmail.org/message/fkqu62uyrmtfb3y4#query:+page:1+mid:fkqu62uyrmtfb3y4+state:results
>
> The magic cookie is not exposed through the API for security reason, it can
>> only be retrieved from going directly into the Calendar UI.
>
>
> While this is pretty old, I've found similar questions from people 
> attempting to do the same as you, and the answers over the years all seem 
> to indicate that this is only exposed via the UI.
>
>
> https://groups.google.com/forum/#!topic/google-calendar-help-dataapi/9Ds8QdaCGFI
> https://support.google.com/code/answer/64253?hl=en
>
> https://stackoverflow.com/questions/5090/retrieve-private-ical-url-for-a-private-calendar-using-the-java-google-calendar
>
> https://stackoverflow.com/questions/6719319/google-api-how-do-i-retrieve-a-calendars-private-address-or-magic-cookie
>
> If you happen to find otherwise, I'd love to know.
>
> Good luck!
> - mingle
>
> On Tue, Oct 23, 2018 at 3:15 PM Caleb Mingle > 
> wrote:
>
>> John,
>>
>> Apologies, I misunderstood your initial question.
>>
>> I wouldn’t be surprised if those values were not exposed via an API, but 
>> I’ll do some research and report back. 
>>
>> - mingle
>>
>> On Tue, Oct 23, 2018 at 13:59 John More > > wrote:
>>
>>> Mingle,
>>> The library I am using is the "google.golang.org/api/calendar/v3" which 
>>> accesses the  https://www.googleapis.com/calendar/v3 REST interface.
>>> I would like to read the secret address of a calendar that I create in a 
>>> G Suite domain user's account so I can dynamically forward it to another 
>>> company that insist they need it to watch for events on the calendar. I 
>>> know it is not appropriate to do this with the private address but this was 
>>> set up before my time and it will be changed but for now history has me 
>>> trapped.
>>> I have tried the API Explorer and I have reviewed the library code and 
>>> can not see where this value is part of any structure.
>>>
>>> Thank you for your reply.
>>>
>>> John
>>>
>>>
>>> On Monday, October 22, 2018 at 12:51:02 AM UTC-4, mingle wrote:
>>>>
>>>> John,
>>>>
>>>> Can you provide more details on which "calendar library" you 
>>>> are referring to?
>>>>
>>>> The link you've highlighted in Google calendar points to a file in 
>>>> iCalendar format. You'll probably want an iCalendar parser to handle the 
>>>> file, I've personally used this one, but it doesn't handle everything in 
>>>> the spec: https://github.com/luxifer/ical.
>>>>
>>>> Depending on the parser that you choose it may have functionality to 
>>>> fetch a file by URL, but most likely you'll need to perform an HTTP 
>>>> request 
>>>> to that URL, read the body, and pass it to a parser.
>>>>
>>>> - mingle
>>>>
>>>>
>>>> On Sun, Oct 21, 2018 at 5:13 AM John More  
>>>> wrote:
>>>>
>>>>> I can not find any documentation indicating how to retrieve the 
>>>>> Calendar Integration Values below. I can create and manipulate calendars 
>>>>> add events etc using the calendar library.
>>>>> Is it possible that these values are simply not available?
>>>>>
>>>>> Thanks any assistance is appreciated.
>>>>>
>>>>> John More
>>>>>
>>>>> [image: Screenshot from 2018-10-21 08-04-52.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...@googlegroups.com.
>>>&

Re: [go-nuts] Calendar Integration Values

[John More]

Mingle,
The library I am using is the "google.golang.org/api/calendar/v3" which 
accesses the  https://www.googleapis.com/calendar/v3 REST interface.
I would like to read the secret address of a calendar that I create in a G 
Suite domain user's account so I can dynamically forward it to another 
company that insist they need it to watch for events on the calendar. I 
know it is not appropriate to do this with the private address but this was 
set up before my time and it will be changed but for now history has me 
trapped.
I have tried the API Explorer and I have reviewed the library code and can 
not see where this value is part of any structure.

Thank you for your reply.

John


On Monday, October 22, 2018 at 12:51:02 AM UTC-4, mingle wrote:
>
> John,
>
> Can you provide more details on which "calendar library" you are referring 
> to?
>
> The link you've highlighted in Google calendar points to a file in 
> iCalendar format. You'll probably want an iCalendar parser to handle the 
> file, I've personally used this one, but it doesn't handle everything in 
> the spec: https://github.com/luxifer/ical.
>
> Depending on the parser that you choose it may have functionality to fetch 
> a file by URL, but most likely you'll need to perform an HTTP request to 
> that URL, read the body, and pass it to a parser.
>
> - mingle
>
>
> On Sun, Oct 21, 2018 at 5:13 AM John More  > wrote:
>
>> I can not find any documentation indicating how to retrieve the Calendar 
>> Integration Values below. I can create and manipulate calendars add events 
>> etc using the calendar library.
>> Is it possible that these values are simply not available?
>>
>> Thanks any assistance is appreciated.
>>
>> John More
>>
>> [image: Screenshot from 2018-10-21 08-04-52.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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Caleb Mingle
>
> mingle.cm | @caleb_io <http://twitter.com/caleb_io>
>

-- 
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] Calendar Integration Values

[John More]

I can not find any documentation indicating how to retrieve the Calendar 
Integration Values below. I can create and manipulate calendars add events 
etc using the calendar library.
Is it possible that these values are simply not available?

Thanks any assistance is appreciated.

John More

[image: Screenshot from 2018-10-21 08-04-52.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Using modules with go test ./...

[John]

Thanks for the reply.  Other that the bug I encountered, this seems to be 
the behavior.

This new "mod" behavior for ./... at least for "go test" seems to be a step 
backwards.  It assumes a kind of test methodology based around a certain 
type of file layout.
If I am at the top of my src/ and I want to test everything underneath, I 
can't without adding some tooling.  I have to go inside a specific module.  
It is nice that it will now test dependencies.  I'm somewhat lost to why 
the go tool would need to change the behavior for "go test ./...", seems 
like adding go.mod wouldn't require this change.  

I imagine I might be in the minority in using test this way.  Its useful 
when you have a small monorepo to do tests.  People who run large monorepos 
must have advanced tooling and individual modules won't notice the behavior 
change.  

But this thread was about if this was expected, not if I think it should be 
changed (I can always open a bug, see if anyone else agrees).  It turns out 
I'm not doing something wrong per say, its just that it doesn't do what I 
want.  I need to adjust my expectations.


On Friday, September 21, 2018 at 11:05:28 AM UTC-7, thepud...@gmail.com 
wrote:
>
> > "What I would expect with 'go test ./...' is behavior similar to 
> what I had before modules."
>
> Hi John, all,
>
> Just to expand slightly on the points from Dave, Scott, and Paul...
>
> I suspect part of what you are encountering is that in general:
>
>   1. Modules are opt-in for Go 1.11, so by design old behavior is 
> preserved by default. This has a few implications, including you get old 
> behavior by default inside GOPATH, but that only applies if you haven't 
> explicitly forced non-default behavior via GO111MODULE. (In your case, you 
> started with GO111MODULE=on set, so that is part of why you are not seeing 
> the old behavior you are used to).
>   
>   2. Most of the modules-specific behavior requires that you be "inside" a 
> module (that is, inside a file tree with a go.mod).
>   
> A consequence of #2 is that if you explicitly ask for modules-specific 
> behavior (e.g., via setting GO111MODULE=on) but are *not* inside a file 
> tree with a 'go.mod' file, then you might see an error message that 
> effectively tells you need to be inside a module. In your case, I think 
> that is why you saw the error "go: cannot determine module path for source 
> directory" when you tried one of your early go commands with GO111MODULE=on 
> but were outside of a file tree with a 'go.mod' file.
>
> In addition, I think in a module-world, something like 'go test ./...' 
> only tests the active module(s), and won't traverse down into an unrelated 
> module that happens to be in a sub-directory of the current module. I 
> believe the doc says that explicitly for a '...' pattern appearing in 'go 
> list', and I think that is true beyond just 'go list', at least as far as I 
> am aware:
>
> From https://tip.golang.org/cmd/go/#hdr-List_packages_or_modules 'go 
> list' documentation:
>
>   "The main module is the module containing the current directory. The 
> active modules are the main module and its dependencies."
>
> and
>
>   "The special pattern "all" specifies all the active modules, first the 
> main module and then dependencies sorted by module path. A pattern 
> containing "..." specifies the active modules whose module paths match the 
> pattern."
>
> I think that explains at least one of the examples you sent where 'go test 
> ./...' did not work as you expected when modules were enabled (because in 
> module-mode, './...' won't match modules that are not dependencies of the 
> current module, even if they are in sub-directories, because they would not 
> be part of the current "active modules").
>
> One related item I'll mention is that a nice part of the modules work is 
> that 'go test all' has been re-defined to be more useful to include all the 
> packages in the current module, plus all the packages they depend on (in 
> other words, all direct and indirect dependencies of the current module).  
> If you want to test the current module and all of its dependencies, 'go 
> test all' would do that (rather than 'go test ./...').
>
> In any event, I am just a member of the community and we are all still 
> learning about modules, so I would be happy to learn if any of what I 
> outlined above doesn't line up with what you are seeing...
>
> Finally, I'm not sure what would be going on with the last piece you 
> reported where 'go env GOMOD' returned the path to a deleted 'go.mod' file.
>
> Best,
> thepudds
>
> On Friday, September 21, 2018 at 11:31:44 AM UTC-4, John wrote:
>>

Re: [go-nuts] Re: Using modules with go test ./...

[John]

Paul, thanks for the explanation.  But I think maybe either I'm missing 
something or I'm not explaining something correctly.

What I would expect with "go test ./..." is behavior similar to what I had 
before modules.  That behavior would be that the go tool would recursively 
run all tests from the directory I am in and below it, regardless if there 
was a package in the current directory. 

I built your example, which works exactly as you expect.  But it doesn't 
solve my issue, which is around "go test ./..." recursively.  As I go back 
up the hierarchy, if I do a go test ./..., it fails.  I could always test 
by just going into the package and running "go test".  I want to be able to 
recursively run tests as the current behavior allows with GOPATH.  If this 
recursive use of "./..." is going away with mod files, then I have to 
adjust to making smart tools.  But I've got to imagine that this isn't the 
intention or that I am still doing something incorrectly. 
 
Additionally, I have also tried to add go.mod files in sub directories that 
contain no go files between the root and the package.  This did not work 
either.

Thanks to everyone (Paul, Dave, Scott) who looked at this.

*Sidenote on my original directory(bug?):*
Interestingly enough, I have made a top level mod file and put a "hello 
world" main.go file.  That did not make this work.
But what looks like a bug is that I deleted both of those files, but if I 
run "go env GOMOD" at src/, I get back a path to a go.mod file that is the 
one I deleted.
Running "go mod tidy" gave the same error, so no auto cleanup
And go init mod also throws the same error.

I'm sure I can clean this up by removing some cached file somewhere.

On Friday, September 21, 2018 at 12:48:13 AM UTC-7, Paul Jolly wrote:
>
> John, 
>
> Scott is on the money with this response: 
>
> > I think you need to have a main module defined so there must be a go.mod 
> in cwd or upwards 
>
> The way to ensure that you are in a valid module context is simply: 
>
> go env GOMOD 
>
> which will return the path to the current (or main) module context 
> (go.mod) if: 
>
> a) you are in module mode (either by being outside of GOPATH or with 
> GO111MODULE=on) and 
> b) there is a go.mod on the directory path from $PWD to the root. 
>
> As you have set GO111MODULE=on you can put your source code pretty 
> much anywhere you like; even within your GOPATH (whether GOPATH is set 
> or not, in the latter case as has been pointed out it defaults to 
> $HOME/go) 
>
> All you are missing is a go.mod file (go end GOMOD would confirm this, 
> and would return "") 
>
> Here's a simple example that shows things working within GOPATH: 
>
> $ export GO111MODULE=on 
> $ export GOPATH=/tmp/tmp.JJgvIDI0Uc 
> $ cd /tmp/tmp.In4INnkIH0 
> $ mkdir -p src/example.com/blah 
> $ cd src/example.com/blah/ 
> $ cat <main.go 
> package main 
> func main() {} 
> EOD 
> $ go env GOMOD 
>
> $ go list 
> go: cannot find main module; see 'go help modules' 
> $ go mod init example.com/blah 
> go: creating new go.mod: module example.com/blah 
> $ go env GOMOD 
> /tmp/tmp.In4INnkIH0/src/example.com/blah/go.mod 
> $ go list 
> example.com/blah 
> $ go test 
> ?   example.com/blah[no test files] 
>
>
> Paul 
>

-- 
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: Using modules with go test ./...

[John]

Gotcha.  Thanks Dave.

Well, looks like I'm going back to my old methods for the time being.  
Thanks everyone!

On Thursday, September 20, 2018 at 4:26:37 PM UTC-7, Dave Cheney wrote:
>
> Sorry, I probably wasn’t clear or didn’t understand that you were asking. 
> I saw that you said GOPATH is not set, it because your code is inside 
> $HOME/go, because of the rules of the default gopath introduced in 1.8, 
> gopath IS actually set. 
>
> To be extra sure, when I’m playing with go modules I use a different 
> directory for my experiments, ~/devel in my case, to avoid conflicts with 
> explicit or implicit gopaths

-- 
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: Using modules with go test ./...

[John]

I think I missed something in this Dave.  Since my directory is already 
$HOME/go, isn't that what I'd want? Since my path is $HOME/go/...?  I found 
the reference in 1.8 release notes (I would not even have gotten close with 
a piece of trivia like that!).  

I did try to move it to another folder, even though I'm not sure why.  I 
just got different errors.

On Thursday, September 20, 2018 at 2:54:27 PM UTC-7, Dave Cheney wrote:
>
> I think because GOPATH is not set it is defaulting to $HOME/go (see Go 1.9 
> release notes, from memory). Try moving your code to another folder.
>
>
>
> On Friday, 21 September 2018 05:21:32 UTC+10, John wrote:
>>
>> Just started playing with modules recently. Having an issue I don't 
>> understand, wondering if anyone has seen it, the few references to the 
>> error did not provide anything I saw relevant for what I'm doing.
>>
>> given a directory structure such as:
>>
>> /go/
>>   src/
>>   pkg/
>>   bin/
>>
>> GOPATH NOT SET
>> GO111MODULE = on
>>
>> If the working directory is:
>> /go/src/
>>
>> go test ./...
>>
>> *Results in:*
>> go: cannot determine module path for source directory /home/jdoak/go/src 
>> (outside GOPATH, no import comments)
>>
>> This also occurs if I do:
>>
>> go test subdir/subdir/packagedir/...
>>
>> But it will work if I do:
>>
>> working directory: /go/src/subdir/subdir/packagedir/
>>
>> go test ./...
>>
>> I'm sure I'm doing something wrong.  If someone could enlighten me.
>>
>>

-- 
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: Using modules with go test ./...

[John]

Thanks for the link.

I did try the following:

   - Adding a main.go file and doing a go mod init, but that fails.
   - Just adding a go.mod file with "module main", which allowed 
   compilation, but nothing else worked.
   - And of course, I added GOPATH back, but that didn't help (and I'm 
   pretty sure I saw it was ignored if I turn modules on).
   
I could write workflow to only run tests if go.mod exists.  That seems to 
defeat the whole ./... argument to the tool.  I just was assuming that I've 
made a mistake somewhere in setting this up.  If that is not the case, I 
can certainly modify what I'm doing.  

On Thursday, September 20, 2018 at 2:15:18 PM UTC-7, Scott Cotton wrote:
>
> I think you need to have a main module defined so there must be a go.mod 
> in cwd or upwards in the directory tree, perhaps also with related .go 
> files (not sure).
>
> There are some issues such as this one 
> <https://github.com/golang/go/issues/27233> where usage is confusing due 
> to a lack of a main module.  They are marked needs fix and go1.1.2. I think 
> your use case is related.  I haven't had a problem with that one because I 
> just set up my workflow to run tests where there are go.mod files.
>
> Best,
> Scott
>
>
>
> On Thursday, 20 September 2018 21:21:32 UTC+2, John wrote:
>>
>> Just started playing with modules recently. Having an issue I don't 
>> understand, wondering if anyone has seen it, the few references to the 
>> error did not provide anything I saw relevant for what I'm doing.
>>
>> given a directory structure such as:
>>
>> /go/
>>   src/
>>   pkg/
>>   bin/
>>
>> GOPATH NOT SET
>> GO111MODULE = on
>>
>> If the working directory is:
>> /go/src/
>>
>> go test ./...
>>
>> *Results in:*
>> go: cannot determine module path for source directory /home/jdoak/go/src 
>> (outside GOPATH, no import comments)
>>
>> This also occurs if I do:
>>
>> go test subdir/subdir/packagedir/...
>>
>> But it will work if I do:
>>
>> working directory: /go/src/subdir/subdir/packagedir/
>>
>> go test ./...
>>
>> I'm sure I'm doing something wrong.  If someone could enlighten me.
>>
>>

-- 
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 modules with go test ./...

[John]

Just started playing with modules recently. Having an issue I don't 
understand, wondering if anyone has seen it, the few references to the 
error did not provide anything I saw relevant for what I'm doing.

given a directory structure such as:

/go/
  src/
  pkg/
  bin/

GOPATH NOT SET
GO111MODULE = on

If the working directory is:
/go/src/

go test ./...

*Results in:*
go: cannot determine module path for source directory /home/jdoak/go/src 
(outside GOPATH, no import comments)

This also occurs if I do:

go test subdir/subdir/packagedir/...

But it will work if I do:

working directory: /go/src/subdir/subdir/packagedir/

go test ./...

I'm sure I'm doing something wrong.  If someone could enlighten me.

-- 
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: bufio.Writer's sticky errors & lost data

[John Floren]

On Thursday, September 20, 2018 at 5:50:51 AM UTC-6, Dean Wang wrote:
>
>
>>  new connection, new underlying io.Writer,  why keep the previous pending 
> data? 
>  
>

It's a new connection to the same destination. I want the bytes I wrote to 
reach that destination, even if we have to negotiate a new connection 
halfway through. 

-- 
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] bufio.Writer's sticky errors & lost data

[John Floren]

If bufio.Writer.Flush() ever sees an error, it sets b.err and will 
immediately return that error on any future calls to Flush: 
https://golang.org/src/bufio/bufio.go?s=14569:14599#L558

Writer.Reset(w io.Writer) will clear the error and set the bufio.Writer to 
use the new io.Writer given, but it also *resets the buffer pointer to 0*, 
losing pending data.

Suppose I have a bufio.Writer wrapping a network connection. If I e.g. 
switch from WiFi to an ethernet connection on my laptop, Flush will return 
an error and thereafter refuse to write to that connection. I can 
re-establish the connection and call Writer.Reset with the new connection, 
but I will lose any pending data.

At bufio.go:580, Flush's error-handling code seems to be updating b.buf and 
b.n as if they might be used later, but a quick look through the code shows 
that if b.err is ever set, b.buf will never be written to the io.Writer.

The same applies if you've set a WriteDeadline on your connection; the 
connection itself may in fact be completely fine, but temporary network 
conditions meant you couldn't meet the deadline. The bufio.Writer, though, 
is broken if it misses a deadline.

What's the right way to handle this? Write our own bufio that lets us reset 
the error and io.Writer while preserving unwritten data?

Thanks,

John

-- 
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: using go modules replace with old repos

[John Shahid]

Ping.

John Shahid  writes:

> Hi all,
>
> Is there a way to use the go module `replace' directive for packages
> that don't have go.mod yet ? I tried doing that and I get the following
> error:
>
>> go: parsing ../pkg/go.mod: open /path/to/pkg/go.mod: no such file or
>> directory
>
> According to https://github.com/golang/go/issues/24110 it looks like
> this is the intended behavior.  My question is why the go tool (e.g. go
> get) can deal with such package when downloading it from github and
> could give it a pseudo version without a go.mod file but refuses to when
> the source code is local.
>
> I'm happy to construct a sample github project to repro the issue if
> that is needed.
>
> 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.

[go-nuts] Working or Not

[John]

I am currently making a program with variables, but when I tried to run it 
says that the variables are not defined. So below are may code for using 
the variable:

func showBoard()  {
 fmt.Println("  1 2 3")
 fmt.Println("a", a1, a2, a3)
 fmt.Println("b", b1, b2, b3)
 fmt.Println("c", c1, c2, c3)
}
PS: I used the newest go version and the atom compiler



 Sincerely


   John

-- 
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'?

[John Shahid]

Agniva De Sarker  writes:

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

Great, thanks!

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

[go-nuts] using go modules replace with old repos

[John Shahid]

Hi all,

Is there a way to use the go module `replace' directive for packages
that don't have go.mod yet ? I tried doing that and I get the following
error:

> go: parsing ../pkg/go.mod: open /path/to/pkg/go.mod: no such file or
> directory

According to https://github.com/golang/go/issues/24110 it looks like
this is the intended behavior.  My question is why the go tool (e.g. go
get) can deal with such package when downloading it from github and
could give it a pseudo version without a go.mod file but refuses to when
the source code is local.

I'm happy to construct a sample github project to repro the issue if
that is needed.

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.

[go-nuts]

[John Shahid]

-- 
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: Working with import "google.golang.org/api/admin/directory/v1"

[John More]

Silviu,
Thank You.
It was my birthday yesterday and I spent all day trying to follow the
source code trail and you provided a great birthday present.
It worked as you advised and I am sure I will have many more occasions to
use this.
One side effect of my day going through the library source code was
increased go knowledge.

Thanks Again

John


On Sun, Aug 26, 2018 at 9:17 AM,  wrote:

> Hi John
>
> If you look at the source code, you will notice that the User struct they
> have makes use of a custom MarshallJSON method, which accepts
> ForceSendFields (as defined inside the User type)
>
> So what you might need to do, is add that "Suspended" into that slice and
> it will marshall it to JSON
>
> See: https://play.golang.org/p/TY-hFUlYewL
>
> Silviu
>
>
> On Saturday, 25 August 2018 23:20:09 UTC-4, John More wrote:
>>
>> I am using the "google.golang.org/api/admin/directory/v1" to access a G
>> Suite account and everything seems to work EXCEPT:
>> The import defines a User structure that includes the following element
>> among many others
>> Suspended bool <https://godoc.org/builtin#bool>
>> `json:"suspended,omitempty"`
>>
>> When set to false the json.Marshal treats this as an empty field which
>> will not allow me to reactivate a user.
>> Calling the API directly without using the library is not an option as I
>> am using a service account which means I have to use a JWT and I really
>> have no idea how to get the Bearer token.
>> Copying the user struct from the library generates a lot of compiler
>> dependency errors
>>
>> If anyone has run into this before.. workarounds or clues are 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.
>



-- 
John More
613-354-1234
613.328.8885

-- 
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] Working with import "google.golang.org/api/admin/directory/v1"

[John More]

I am using the "google.golang.org/api/admin/directory/v1" to access a G 
Suite account and everything seems to work EXCEPT:
The import defines a User structure that includes the following element 
among many others
Suspended bool  `json:"suspended,omitempty"` 

When set to false the json.Marshal treats this as an empty field which will 
not allow me to reactivate a user. 
Calling the API directly without using the library is not an option as I am 
using a service account which means I have to use a JWT and I really have 
no idea how to get the Bearer token.
Copying the user struct from the library generates a lot of compiler 
dependency errors

If anyone has run into this before.. workarounds or clues are 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.