from:"Bakul Shah"

Re: [go-nuts] Failure in file seek

2024-04-08 Thread 'Bakul Shah' via golang-nuts

> offset, err := f.Seek(0, 10)

The second argument needs to be one of io.{SeekStart,SeekCurrent,SeekEnd} (0, 1 
or 2).
go doc os.File.Seek

> On Apr 8, 2024, at 2:24 PM, Nikhilesh Susarla  wrote:
> 
> github/file-seek/main.go 
> 
> 
> I did write with ReadOnly also and it failed. 
> 
> Sorry, I assumed both Append and ReadOnly fails.
> 
> On Tuesday 9 April 2024 at 02:14:48 UTC+5:30 Ian Lance Taylor wrote:
>> On Mon, Apr 8, 2024, 3:33 PM Nikhilesh Susarla > 
>> wrote:
>>> I wanted to seek around a file by opening it using read-only, but then I 
>>> get this error called "Invalid argument"
>>> 
>>> https://go-review.googlesource.com/c/go/+/14881
>>> 
>>> I read the above link and they say it is not supported to seek around. I 
>>> tried direct lseek in c language and it failed with same. 
>>> 
>>> Is there any way ?
>> 
>> 
>> What that link says is that if you open the file with O_APPEND then you 
>> can't Seek.  Are you opening with O_APPEND?
>> 
>> If not you will need to provide more information, such as a small program 
>> that demonstrates the problem.
>> 
>> 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/536e18e8-4dd3-44a4-8893-d5fa22836996n%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/BB230EEB-9928-4EA3-918F-BAA598137519%40iitbombay.org.

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

2024-01-13 Thread Bakul Shah

Fair enough!

I replied as I found a factor of 60 a bit surprising. Though I shouldn't have 
been -- my n digits of pi scheme program was consistently about 16-17 times 
slower than gmp based one (at least up to 1E9), using the same algorithm 
(Chudnovsky's), which is also highly dependent on multiplication speed. And 
both (gambit-scheme and gmp) use faster algorithms for very large numbers. 
Adding these faster algorithms to math/big is probably not justifiable

Julia seems to use libgmp. "info gmp" reveals it implements Luchny's algorithm.

> On Jan 13, 2024, at 4:07 PM, Rob Pike  wrote:
> 
> This is getting interesting but maybe only for me, so I'll stop here.
> 
> I did some profiling and the majority of the time is spent in 
> math/big.addMulVVW. Thinking I might be doing something stupid, I compared it 
> with the Go implementation at 
> http://www.luschny.de/math/factorial/scala/FactorialScalaCsharp.htm, and 
> found that my version (although "straightforward"), is about the same amount 
> of code but without special casing and support tables, yet about 25% faster - 
> and yes, they get the same answer.
> 
> So I believe the factor of 60 comes from comparing an implementation in a 
> language and libraries designed for numerical computation against a much less 
> specialized and optimized world. Or perhaps from Julia using a different and 
> dramatically more efficient algorithm. It does seem like a big gap, but I am 
> no expert in this area.
> 
> Maybe worth investigating further but not by me.
> 
> -rob
> 
> On Sun, Jan 14, 2024 at 9:31 AM Rob Pike  <mailto:r...@golang.org>> wrote:
>> Oh, I did say my implementation was straightforward. It's free of any clever 
>> multiplication algorithms or mathematical delights. It could easily be 
>> giving up 10x or more for that reason alone. And I haven't even profiled it 
>> yet.
>> 
>> -rob
>> 
>> 
>> On Sat, Jan 13, 2024 at 7:04 PM Bakul Shah > <mailto:ba...@iitbombay.org>> wrote:
>>> FYI Julia (on M1 MBP) seems much faster:
>>> 
>>> julia> @which factorial(big(1))
>>> factorial(x::BigInt) in Base.GMP at gmp.jl:645
>>> 
>>> julia> @time begin; factorial(big(1)); 1; end
>>>  27.849116 seconds (1.39 M allocations: 11.963 GiB, 0.22% gc time)
>>> 
>>> Probably they use Schönhage-Strassen multiplication algorithm for very 
>>> large numbers as the 1E8! result will have over a 3/4 billion digits. I 
>>> should try this in Gambit-Scheme (which has an excellent multiply 
>>> implementation).
>>> 
>>>> On Jan 12, 2024, at 9:32 PM, Rob Pike >>> <mailto:r...@golang.org>> wrote:
>>>> 
>>>> Thanks for the tip. A fairly straightforward implementation of this 
>>>> algorithm gives me about a factor of two speedup for pretty much any 
>>>> value. I went up to 1e8!, which took about half an hour compared to nearly 
>>>> an hour for MulRange.
>>>> 
>>>> I'll probably stick in ivy after a little more tuning. I may even try 
>>>> parallelization.
>>>> 
>>>> -rob
>>>> 
>>>> 
>>>> On Tue, Jan 9, 2024 at 4:54 PM Bakul Shah >>> <mailto:ba...@iitbombay.org>> wrote:
>>>>> For that you may wish to explore Peter Luschny's "prime swing" factorial 
>>>>> algorithm and variations!
>>>>> https://oeis.org/A000142/a000142.pdf
>>>>> 
>>>>> And implementations in various languages including go: 
>>>>> https://github.com/PeterLuschny/Fast-Factorial-Functions
>>>>> 
>>>>>> On Jan 8, 2024, at 9:22 PM, Rob Pike >>>>> <mailto:r...@golang.org>> wrote:
>>>>>> 
>>>>>> Here's an example where it's the bottleneck: ivy factorial
>>>>>> 
>>>>>> 
>>>>>> !1e7
>>>>>> 1.20242340052e+65657059
>>>>>> 
>>>>>> )cpu
>>>>>> 1m10s (1m10s user, 167.330ms sys)
>>>>>> 
>>>>>> 
>>>>>> -rob
>>>>>> 
>>>>>> 
>>>>>> On Tue, Jan 9, 2024 at 2:21 PM Bakul Shah >>>>> <mailto:ba...@iitbombay.org>> 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)). F

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

2024-01-13 Thread Bakul Shah

FYI Julia (on M1 MBP) seems much faster:

julia> @which factorial(big(1))
factorial(x::BigInt) in Base.GMP at gmp.jl:645

julia> @time begin; factorial(big(1)); 1; end
 27.849116 seconds (1.39 M allocations: 11.963 GiB, 0.22% gc time)

Probably they use Schönhage-Strassen multiplication algorithm for very large 
numbers as the 1E8! result will have over a 3/4 billion digits. I should try 
this in Gambit-Scheme (which has an excellent multiply implementation).

> On Jan 12, 2024, at 9:32 PM, Rob Pike  wrote:
> 
> Thanks for the tip. A fairly straightforward implementation of this algorithm 
> gives me about a factor of two speedup for pretty much any value. I went up 
> to 1e8!, which took about half an hour compared to nearly an hour for 
> MulRange.
> 
> I'll probably stick in ivy after a little more tuning. I may even try 
> parallelization.
> 
> -rob
> 
> 
> On Tue, Jan 9, 2024 at 4:54 PM Bakul Shah  <mailto:ba...@iitbombay.org>> wrote:
>> For that you may wish to explore Peter Luschny's "prime swing" factorial 
>> algorithm and variations!
>> https://oeis.org/A000142/a000142.pdf
>> 
>> And implementations in various languages including go: 
>> https://github.com/PeterLuschny/Fast-Factorial-Functions
>> 
>>> On Jan 8, 2024, at 9:22 PM, Rob Pike >> <mailto:r...@golang.org>> wrote:
>>> 
>>> Here's an example where it's the bottleneck: ivy factorial
>>> 
>>> 
>>> !1e7
>>> 1.20242340052e+65657059
>>> 
>>> )cpu
>>> 1m10s (1m10s user, 167.330ms sys)
>>> 
>>> 
>>> -rob
>>> 
>>> 
>>> On Tue, Jan 9, 2024 at 2:21 PM Bakul Shah >> <mailto:ba...@iitbombay.org>> 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 >>>> <mailto:g...@golang.org>> 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

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

2024-01-08 Thread Bakul Shah

For that you may wish to explore Peter Luschny's "prime swing" factorial 
algorithm and variations!
https://oeis.org/A000142/a000142.pdf

And implementations in various languages including go: 
https://github.com/PeterLuschny/Fast-Factorial-Functions

> On Jan 8, 2024, at 9:22 PM, Rob Pike  wrote:
> 
> Here's an example where it's the bottleneck: ivy factorial
> 
> 
> !1e7
> 1.20242340052e+65657059
> 
> )cpu
> 1m10s (1m10s user, 167.330ms sys)
> 
> 
> -rob
> 
> 
> On Tue, Jan 9, 2024 at 2:21 PM Bakul Shah  <mailto:ba...@iitbombay.org>> 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 >> <mailto:g...@golang.org>> 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 >> <mailto:janno...@gmail.com>> 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.Ma

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

2024-01-08 Thread Bakul Shah

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

Re: [go-nuts] Can we not invoke methods on types referring to generics?

2023-10-20 Thread Bakul Shah

On Oct 19, 2023, at 9:02 PM, Nurahmadie Nurahmadie  wrote:
> 
> Is it not possible to have both _auto_ downcasting and new method binding to 
> work in Go?

What you are suggesting may make things more *convenient* but
at the same time the potential for accidental mistakes goes
up. The key is find a happy medium. Not too much discipline,
not too much freedom!


-- 
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/BB7C6A9A-F0BE-4180-B495-93E4B195EA97%40iitbombay.org.

Re: [go-nuts] Generic "nillable" constraint

2023-10-17 Thread Bakul Shah

I'd happy with

if val { ... }

and

if !val { ... }

Instead of comparing val with an explicit zero but don't feel strongly about 
this.

> On Oct 17, 2023, at 9:09 PM, Jon Watte  wrote:
> 
> Circling back to this, because it came up today again.
> 
> Here's the generic function I want to write. It comes up in a lot of function 
> composition, which in turn comes up in a lot of interface adapters and such:
> 
> func maybeAssign[T any](dst *T, src T, name string) {
> if *dst != nil { // any can't be compared with nil
> panic(fmt.Errorf("too many %s arguments", name))
> }
> *dst = src
> }
> 
> Using this function in each assignment, instead of inlining the four-line 
> construct with panic, can save a lot of space and make code a lot more 
> readable.
> The above doesn't work, because not every type can be assigned nil.
> The following also doesn't work:
> 
> func maybeAssign[T comparable](dst *T, src T, name string) {
> var zero T
> if *dst != zero { // interface and other nillable types can't be compared 
> to zero
> panic(fmt.Errorf("too many %s arguments", name))
> }
> *dst = src
> }
> 
> Because interface values aren't comparable. (As aren't chans, maps, etc, but 
> THOSE can be jammed into various interface constructs, whereas "any 
> interface" cannot, because "interface{}" doesn't actually mean "any 
> interface")
> 
> Let me try to answer:
> 
> > Why is the specific split into (interfaces, pointers, slices, functions, 
> > maps, channels) and (numbers, booleans, strings, structs, arrays) a 
> > particularly important one?
> 
> Because, while go tries very hard to make sure every storable type has a 
> "zero value," it somehow decides that you can't necessarily COMPARE to that 
> zero value.
> But the whole point of zero values is that you can tell them from non-zero 
> values!
> So, the language has introduced a work-around with the concept of "I can 
> compare to nil" for these reference types that aren't comparable to their 
> zero value.
> But generics don't allow us to sense or make use of this, so generics can't 
> express what the regular language can express. Even a very simple case like 
> the above, can't currently be expressed, and this leads to more verbose code 
> that's harder to read and harder to work with. (Granted, this is my opinion, 
> but I'm not alone.)
> 
> If the language instead changes such that chans and interfaces and maps 
> become comparable, then that's fine -- that solves the problem! But that 
> seems like a much bigger change than a constraint that senses exactly the 
> "can compare to nil" semantic.
> 
> If the language instead changes so that nil means "the zero value" in 
> general, and it so happens that these nil-comparable types can be compared to 
> nil without any particular qualification, that also solves the problem. That 
> might indeed be a good solution -- but if so, it'd be nice to know what we 
> can do to make that happen, and what the other opposition to that change 
> might be, because that change also feels much less narrow than a "nil" type 
> constraint.
> 
> 
> Sincerely,
> 
> Jon Watte
> 
> 
> --
> "I find that the harder I work, the more luck I seem to have." -- Thomas 
> Jefferson
> 
> 
> On Tue, Oct 3, 2023 at 10:41 PM Axel Wagner  > wrote:
>> Oh (sorry, being forgetful) and re "it's less of a new mechanism than 
>> introducing a zero identifier": #62487 
>>  introduces even less new 
>> mechanism, by expanding comparison to (and assignment of) `nil` to all types 
>> inside a generic function. It's not a new class of constraint, it just 
>> special-cases `nil` a bit more. So it is still a far more general mechanism, 
>> that solves more problems than `nilable` constraint, while requiring fewer 
>> (or at worst the same number of) new concepts.
>> 
>> On Wed, Oct 4, 2023 at 7:36 AM Axel Wagner > > wrote:
>>> (correction: It should be Convert[J isinterface, T J]. I changed the name 
>>> from I to J to be more readable and then missed one occurrence)
>>> 
>>> On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner >> > wrote:
 On Wed, Oct 4, 2023 at 6:54 AM Jon Watte >>> > wrote:
> > where it is important to permit only type arguments that can be 
> > compared to nil
> 
> I see! As in, if we somehow got a "equalszero" constraint, then that 
> constraint would solve the problem I illustrate.
> I believe that assertion is correct, but I also believe that is a 
> stronger assertion, and also that it introduces more of a new concept 
> than a simple "nil" constraint. (Unless you're looking for some way to 
> make "any" work, and introduce a zero keyword or something...)
 
 Yes, that is what #61372  proposes: Introduce 
 a `zero` predeclared

Re: [go-nuts] Why causes []any trouble in type equations?

2023-10-11 Thread Bakul Shah

On Oct 11, 2023, at 11:09 AM, Torsten Bronger  
wrote:
> 
> Then, all boils down to the fact that you can’t pass []float64 as an
> []any.  To be honest, I still don’t fully understand why this is
> forbidden, so I just accept that the language does not allow it.

I think in the first case []any is really []interface{}
and []float64 is not compatible with it. While in the second
case []E where E is any type is a *constraint*. That is "any"
has two different meanings in two different contexts.

-- 
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/01E7C73A-AA08-48D1-A76C-8FFD3A208CC7%40iitbombay.org.

Re: [go-nuts] no way to pause `Listen` on net connections

2023-07-24 Thread Bakul Shah

You can do a non-blocking select on a channel prior to l.Accept(). If there is 
a pause message, you do a blocking select on the same channel for an resume or 
finish message. A separate goroutine can send you those messages depending on 
conditions under which you want to pause or resume.

If the above doesn't make sense write a sample program on play.golang.org, 
which does roughly want you want except for pause/resume, and post a link here 
and we can modify it for pause/resume.

> On Jul 21, 2023, at 10:47 PM, David N  wrote:
> 
> I've posted this question on stackoverflow 
> ,
>  discussed it with some members of the golang community, and I was encouraged 
> to post here.
> 
> Problem: I have a secure application and I want to pause/resume accepting 
> network connections, calling `l.Accept()` blocks the thread, thus you can't 
> pause in a single-thread program. You can use goroutines but that still isn't 
> ideal, as the routine would still accept the connection first and only then 
> can close it if you're in "pause" mode.
> 
> This could be solved by:
> - having a non-blocking, async, `l.Accept()`
> - returning a handle to (accepting) goroutine and killing/re-creating it from 
> main thread
> - accepting connections in a separate process and communicating over a socket
> 
> The 1st one doesn't exist, the 2nd one is not accepted by the language 
> designers, and the 3rd one is unnecessarily complex and prone to break.
> 
> This looks like a shortcoming of golang, is it worth discussing further with 
> lang designers?
> 
> -- 
> 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/CAN7%3DS7htWfYUQmd3H8GiWoWSaei1qU-FMcpqdyccFkXN1kmsWg%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/8EF29629-1611-4B38-B096-0F181A0DC1E0%40iitbombay.org.

Re: [go-nuts] memory safe languages question

2023-07-23 Thread Bakul Shah

The NSA paper 

 says

Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®

Note "Some"; it is not an exhaustive list of memory safe languages. Presumably 
these languages are mentioned because of their current popularity?

> On Jul 23, 2023, at 5:23 PM, Robert Solomon  wrote:
> 
> I've been reading that the NSA wrote a position paper last year about memory 
> safe languages, which include C#, Go, Java, Ruby, Rust and Swift.
> 
> It's clear to me why C and C++ are not on that list.
> 
> I always thought that Ada sought to be memory safe, or is equivalent to that 
> by saying that Ada focuses on proving programs to be correct.
> Why isn't Ada considered memory safe, at least in the eyes of the NSA?
> 
> 
> -- 
> 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/bba0b21e-5e34-4529-9878-5453e099a053n%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/AD127282-B144-4EBB-B153-66D20DC93707%40iitbombay.org.

Re: [go-nuts] Go routines consuming memory

2023-06-06 Thread Bakul Shah

You should read the comments following the article you referenced. In addition 
there is a long thread on hackernews that might be worth browsing:
https://news.ycombinator.com/item?id=36024209

But if you want a real insight into how concurrent programs behave, you are 
better off writing your own toy benchmarking programs that focus on various 
aspects of concurrency. Then you can modify them to measure such metrics for 
your specific applications.

> On Jun 6, 2023, at 7:58 PM, Nikhilesh Susarla  wrote:
> 
> I was going through a blog where they compare different language threads to 
> see how much memory they consume for a million tasks. 
> 
> Blog : https://pkolaczk.github.io/memory-consumption-of-async/
> 
> Do we have any benchmarking/report before that Go routines take more memory 
> with more threads? 
> 
> I know we can't consider it to be ideal but any reasons that the memory 
> spiked up? 
> Is there any blog to read more about go routines and their memory 
> consumptions? 
> 
> Thank you
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/0af076cc-8b5d-491b-88f5-599dbd37c056n%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/DC4AD442-587D-4070-8B5D-503466F00A7B%40iitbombay.org.

Re: [go-nuts] Short Variable Declarations Are Oversold

2023-04-22 Thread Bakul Shah

If you are not using an IDE, you can always use, for example, "go doc os.Open" 
to see what os.Open returns.

For user packages, you can use for example 
"go doc github.com/benhoyt/goawk/parser.ParseProgram" from your directory that 
contains "go.mod" for your program.

> On Apr 22, 2023, at 3:31 PM, jlfo...@berkeley.edu  
> wrote:
> 
> import “os”
> func main() {
>   file, _ := os.Open(os.Args[1])
>   myfunc(file)
> }
> 
> func myfunc(file ???) {
> }
> 
> What type should I use to declare “file” in the parameter list for myfunc()? 
> As a new Go programmer I have to admit that I haven’t memorized all the types 
> used in the Go standard library. So, I have to break off working on myfunc() 
> to look up the type returned by os.Open(). This isn’t a huge deal, but it’s a 
> distraction and can waste time. I suppose that as I gain experience with Go, 
> I’ll have to do this less and less.
> 
> But, it doesn’t matter how experienced I am with Go when I start using 
> user-defined types from packages that aren’t in the Go standard library. For 
> example (from Ben Hoyt’s excellent goawk program):
> 
> import "github.com/benhoyt/goawk/parser 
> "
> func main() {
> prog, err := parser.ParseProgram(fileReader.Source(), parserConfig)
> myfunc(prog)
> }
> 
> func myfunc(prog ???) {
> }
> 

-- 
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/B6FBE67E-22AA-4D85-8B7E-032B722CE21D%40iitbombay.org.

Re: [go-nuts] Interesting "select" examples

2023-04-07 Thread Bakul Shah



> On Apr 4, 2023, at 6:20 AM, Jesper Louis Andersen 
>  wrote:
> 
> On Tue, Apr 4, 2023 at 2:22 AM Nigel Tao  > wrote:
>> 
>> I'd have to study mux9p for longer, but its select chooses between two
>> receives, so it could possibly collapse to a single heterogenous
>> channel. Indeed, both its channels are already heterogenous in some
>> sense. Both its processTx and processRx methods say "switch
>> m.tx.Type".
>> 
> 
> If you crank that idea to the max, you can get away with a single mailbox for 
> a goroutine, much like in the sense Erlang is doing it. This approach, 
> however, sacrifices type information which is currently being upheld by the 
> ability to select on multiple channels, each of which have different types. 
> In my experience, the concurrency primitives are malleable in many 
> programming languages, and you can implement one model with another, albeit 
> at a heavy efficiency penalty due to translation.

Note that in Erlang (as well as Hewitt's pure Actor Model) a send never blocks.
This means an Erlang process mailbox can grow unbounded (or bounded only
by available memory) and you need app specific ways to deal with that. In Go
a channel is bounded; which implies a send can block.

Nigel Tao wrote in his original message
it may be possible to work around that by downstream
actors sending "I'm ready to receive" events onto the upstream actor's
heterogenous input channel.

Which made me wonder if the actors he is talked about are actors in the sense
of the Actor Model or Erlang (not the same but close) or if he was using it more
generically -- an entity carrying out some action.

> I wouldn't be surprised if you find that a simpler model will work in 95% of 
> all cases, and that you can find workarounds for the remaining 5% to the 
> point where you are going to ask "what's the point?" I think the answer is 
> "elegance and simplicity".

I would think it is more a question of which model he wants to implement (as 
why) as Go is based on Hoare's CSP model which is quite different from the 
Actor concurrency model

> A view: a select statement is a synchronization of an event. A channel read 
> or a channel write is an event. The select statement is an algebraic concat 
> operation, in the sense it takes an array of such events and produces a new 
> event. We often think of these events as being either "we receive something" 
> or "we send something". But select-statements also allow for their 
> combination of "we either send or receive something". Sometimes, serializing 
> those events into a "send, then receive" or "receive, then send" pattern is 
> fairly easy. Sometimes, it is exceedingly hard to pull off, and the parallel 
> send/recv pattern is just that much more elegant and clearer. The key problem 
> is that sends and/or receives can block, thus obstructing the other event 
> from being processed. You can alleviate this by tasting each channel through 
> a poll. But those solutions often end up being convoluted.

You can always add more goroutines to avoid selecting over more than one 
channel!

-- 
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/EA754B2C-B1C1-4E45-B26E-B3E0D69C2843%40iitbombay.org.

Re: [go-nuts] Upgradable RLock

2023-02-04 Thread Bakul Shah

You can implement your own multiple-reader-single-writer-lock using what Go 
gives you.
For example: 
https://eli.thegreenplace.net/2019/implementing-reader-writer-locks/

> On Jan 30, 2023, at 4:42 PM, Robert Engels  wrote:
> 
> Yes but only for a single reader - any concurrent reader is going to 
> park/deschedule. 
> 
> There’s a reason RW locks exist - and I think it is pretty common - but agree 
> to disagree :)
> 
>> On Jan 30, 2023, at 6:23 PM, Ian Lance Taylor  wrote:
>> 
>> On Mon, Jan 30, 2023 at 1:00 PM Robert Engels  wrote:
>>> 
>>> Pure readers do not need any mutex on the fast path. It is an atomic CAS - 
>>> which is faster than a mutex as it allows concurrent readers. On the slow 
>>> path - fairness with a waiting or active writer - it degenerates in 
>>> performance to a simple mutex.
>>> 
>>> The issue with a mutex is that you need to acquire it whether reading or 
>>> writing - this is slow…. (at least compared to an atomic cas)
>> 
>> The fast path of a mutex is also an atomic CAS.
>> 
>> Ian
>> 
> On Jan 30, 2023, at 2:24 PM, Ian Lance Taylor  wrote:
 
 On Mon, Jan 30, 2023 at 11:26 AM Robert Engels  
 wrote:
> 
> I don’t think that is true. A RW lock is always better when the reader 
> activity is far greater than the writer - simply because in a good 
> implementation the read lock can be acquired without blocking/scheduling 
> activity.
 
 The best read lock implementation is not going to be better than the
 best plain mutex implementation.  And with current technology any
 implementation is going to require atomic memory operations which
 require coordinating cache lines between CPUs.  If your reader
 activity is so large that you get significant contention on a plain
 mutex (recalling that we are assuming the case where the operations
 under the read lock are quick) then you are also going to get
 significant contention on a read lock.  The effect is that the read
 lock isn't going to be faster anyhow in practice, and your program
 should probably be using a different approach.
 
 Ian
 
>>> On Jan 30, 2023, at 12:49 PM, Ian Lance Taylor  wrote:
>> 
>> On Sun, Jan 29, 2023 at 6:34 PM Diego Augusto Molina
>>  wrote:
>>> 
>>> From times to times I write a scraper or some other tool that would 
>>> authenticate to a service and then use the auth result to do stuff 
>>> concurrently. But when auth expires, I need to synchronize all my 
>>> goroutines and have a single one do the re-auth process, check the 
>>> status, etc. and then arrange for all goroutines to go back to work 
>>> using the new auth result.
>>> 
>>> To generalize the problem: multiple goroutines read a cached value that 
>>> expires at some point. When it does, they all should block and some I/O 
>>> operation has to be performed by a single goroutine to renew the cached 
>>> value, then unblock all other goroutines and have them use the new 
>>> value.
>>> 
>>> I solved this in the past in a number of ways: having a single 
>>> goroutine that handles the cache by asking it for the value through a 
>>> channel, using sync.Cond (which btw every time I decide to use I need 
>>> to carefully re-read its docs and do lots of tests because I never get 
>>> it right at first). But what I came to do lately is to implement an 
>>> upgradable lock and have every goroutine do:
>> 
>> 
>> We have historically rejected this kind of adjustable lock.  There is
>> some previous discussion at https://go.dev/issue/4026,
>> https://go.dev/issue/23513, https://go.dev/issue/38891,
>> https://go.dev/issue/44049.
>> 
>> For a cache where checking that the cached value is valid (not stale)
>> and fetching the cached value is quick, then in general you will be
>> better off using a plain Mutex rather than RWMutex.  RWMutex is more
>> complicated and therefore slower.  It's only useful to use an RWMutex
>> when the read case is both contested and relatively slow.  If the read
>> case is fast then the simpler Mutex will tend to be faster.  And then
>> you don't have to worry about upgrading the lock.
>> 
>> 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/CAOyqgcXNVFkc5H-L6K4Mt81gB6u91Ja07hob%3DS8Qwgy2buiQjQ%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

Re: [go-nuts] Guaranteeing deterministic execution of Golang code

2023-01-16 Thread Bakul Shah

I would think the map iteration order is arbitrary but deterministic. That is, 
the same set of keys will be iterated the same way every time. This is not the 
case with the select statement.

> On Jan 16, 2023, at 1:34 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> I think the question of "when is a Go program deterministic" makes full 
> sense, FWIW. Because being deterministic is a desirable property of many 
> programs (compilers being one obvious example). So considering this question 
> gives you insight into how to write such programs. For example, realizing 
> that map iteration order is not defined to be deterministic leads you to sort 
> keys of a map before output, if you want deterministic output.

-- 
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/95F0F462-C4C5-4B59-9FC8-71EB6217862B%40iitbombay.org.

Re: [go-nuts] Re: Unicode variable name error

2022-11-06 Thread Bakul Shah

In Indic scripts in certain contexts you have to use a vowel sign for the typography to make sense; you can’t use a vowel letter in its place. So for example the middle “ku” in my name has to be written as ક+ુ — which will be rendered as કુ — even though it is equivalent to ક+્+ઉ. Also, “halant” (્), is not a letter! I would strongly urge Nikhilesh and other people wanting to use any Indic script to *avoid* it (even if Go implements TR31 as in Swift) and instead use the lossless transliteration scheme of IAST if the program calls for an Indian word as a Go object name. https://en.wikipedia.org/wiki/International_Alphabet_of_Sanskrit_Transliteration On Nov 6, 2022, at 4:02 AM, Rob Pike wrote:

% unicode -d పే
U+0C2A 'ప' telugu letter pa
U+0C47 'ే' telugu vowel sign ee

% unicode -U C2A C47

U+0C2A 'ప' TELUGU LETTER PA
category: Lo
canonical combining classes: 0
bidirectional category: L
mirrored: NU+0C47 'ే' TELUGU VOWEL SIGN EE

category: Mn
canonical combining classes: 0
bidirectional category: NSM
mirrored: N%The problem is the second code point, U+0C47, Telugu vowel sign EE. It is not in the letter class. If I change your program to use just the first code point, it works: https://play.golang.com/p/eNvuZH33s65The rules for identifiers in Go were chosen because they are easy to implement, but they do have the problem that they do not treat all languages equally. They may expand one day, but at the moment this is the situation.There are a number of open issues around this. Start with https://github.com/golang/go/issues/20706 if you want to read more.-robOn Sun, Nov 6, 2022 at 9:52 PM Konstantin Khomoutov wrote:On Sun, Nov 06, 2022 at 01:45:53PM +0530, Nikhilesh Susarla wrote:

>> Per the Go spec[1], an identifier consists of a Unicode letter followed by
>> zero or more Unicode letters or digits. The character పే is in the Unicode
>> category nonspacing mark rather than the category letter.
[...]
> So, if the unicode letters are there in the nonspacing mark as you
> mentioned they can't be used right ?

I sense the source of your misunderstanding might be rooted in your lack of
certain basics about Unicode. You seem to call "a letter" anything which may
appear in a text document (a Go source code file is a text document) but this
it not true. Maybe that's just a terminological problem, but still the fact
is, the Unicode standard calls "letters" a very particular group of things
among those the Unicode standard describes. To give a very simplified example,
in the text string "foo bar" there are six letters (five distinct) and one
space character which is not a letter. The charcter being discussed is not a
letter in Unicode, either.

--
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/20221106105154.xkoemtt6tx25flam%40carbon.

Re: [go-nuts] Error Handling Question

2022-10-25 Thread Bakul Shah

On Oct 25, 2022, at 2:28 PM, 'Daniel Lepage' via golang-nuts 
 wrote:
> 
> In contrast, the modern Go version buries the "normal" flow in a pile of 
> error handling, and IMO is a lot harder to follow:
> 
> foo, err := Foo()
> if err != nil {
> return fmt.Errorf("enforcing foo limit: %w", err)
> }
> limit, err := Limit()
> if err != nil {
> return fmt.Errorf("enforcing foo limit: %w", err)
> }
> if foo > limit {
> foo, err = DiminishFoo(foo)
> if err != nil {
> return fmt.Errorf("enforcing foo limit: %v", err)
> }
> if foo > limit {
> return fmt.Errorf("foo value %d exceeds limit %d, even after 
> diminishment", foo, limit)
> }
> }

Some languages have optional types so for example you can do

foo := Foo() or { return fmt.Error("enforcing foo limit: %w", err) }
limit := Limit() or { return fmt.Errorf("enforcing foo limit: %w", err) }
if foo > limit {
...
}

If you just want to punt the error to the caller, you do

foo := Foo()?
limit := Limit()?

etc. Now this is just syntactic sugar and semantically almost
identical to what Go does. Except that err becomes a builtin.
Making it a builtin can potentially be useful as the compiler
can embed information such as which line or expression generated
the error (or passed it on) for debugging.

A function returning such a value may be declared as

fn Foo() ?typeFoo {
var foo typeFoo
...
return foo
...
return err...
}

I find this easier to read as the error handling code doesn't
overwhelm the non-error logic and the compiler can check if a
Foo() caller doesn't handle the error case and print a message.
And I find this much less odious than try ... catch ... +
compilers can't easily check if exceptions are indeed handled
without adding more boilerplate code.

Though I don't think Go authors like this style. 

-- 
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/03295133-85E2-4358-8910-E95612C026BF%40iitbombay.org.

Re: [go-nuts] behavior of %f

2022-10-10 Thread Bakul Shah

On Oct 10, 2022, at 5:40 PM, Dante Castagnoli  
wrote:
> 
> Also, if you were to take an int(f), you will note that it returns "0", and 
> not "1".

%0.3f does *rounding*, while int(f) does *truncation*.
1.0 is closer to 0.... than 0.999 is to 0....

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B51E4191-D268-4F17-BD50-1FEB59B94379%40bitblocks.com.

Re: [go-nuts] Go routine context

2022-10-01 Thread Bakul Shah

Quoting from this article: "Virtual threads (JEP 425 
) make it cost-effective to dedicate a thread to 
every such I/O operation, but managing the huge number of threads that can 
result remains a challenge."

My quick take: may be this is due to "old thread think" as virtual threads are 
so new in Java? Has managing large number of goroutines been a problem?

One use I can see for giving each thread a handle is for doing user level 
scheduling and in general treating them as first class objects. This may be a 
cost vs benefit issue. 

> On Sep 30, 2022, at 10:49 PM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> Oh, following the link about Structured Concurrency at the end brings you to 
> https://openjdk.org/jeps/428 
> That *does* indeed seem to contain discussion about relevant topics. Perhaps 
> that's the link you intended to post?
> 
> On Sat, Oct 1, 2022 at 7:45 AM Axel Wagner  > wrote:
> I've at least skimmed the article and I can't find any of the arguments you 
> say are there.
> For thread locals it says, if anything, that they should be avoided with 
> virtual threads - at least for some uses (the ones that you'd use a sync.Pool 
> for in Go). On coloring it only talks about the advantages of virtual threads 
> over async/await, which, well most Gophers will agree with.
> 
> Apart from these, I can't find anything that I could reasonably connect to 
> context.Context - the article seems almost exclusively an introduction to 
> virtual threads and an explanation on how they differ from operating system 
> threads. In particular, I don't see anything in this article which could 
> address the arguments Ian mentioned.
> 
> It teases at more articles, about "Structured Concurrency" and "Extent local 
> variables" - the latter sounds as if it *could* be what you talk about, but 
> that article doesn't seem to exist yet.
> 
> On Sat, Oct 1, 2022 at 6:15 AM Robert Engels  > wrote:
> Again, please read the paper. The arguments you make are refuted. The lack of 
> routine context is a burden on the Go ecosystem and makes debugging highly 
> concurrent Go systems far more difficult than similar systems in Java. 
> 
>> On Sep 30, 2022, at 11:09 PM, Rob Pike > > wrote:
>> 
>> 
>> One of the critical decisions in Go was not defining names for goroutines. 
>> If we give threads/goroutines/coroutines (TGCs) names or other identifiable 
>> state, such as contexts, there arises a tendency to push everything into one 
>> TGC. We see what this causes with the graphics thread in most modern 
>> graphics libraries, especially when using a threading-capable language such 
>> as Go. You are restricted in what you can do on that thread, or you need to 
>> do some sort of bottlenecking dance to have the full language available and 
>> still honoring the requirements of a single graphics thread.
>> 
>> One way to see see what this means: Long ago, people talked of a "thread per 
>> request"  model, and honestly it was, or would have been, an improvement on 
>> standard practice at the time. But if you have cheap TGCs, there is no need 
>> to stop there: You can use multiple independently executing TGCs to handle a 
>> request, or share a TGC between requests for some part of the work (think 
>> database access, for example). You have the whole language available to you 
>> when programming a request, including the ability to use TGCs.
>> 
>> Like Ian, I have not read this paper, but I take it as a tenet that it is 
>> better to keep goroutines anonymous and state-free, and not to bind any 
>> particular calculation or data set to one thread of control as part of the 
>> programming model. If you want to do that, sure, go for it, but it's far too 
>> restrictive to demand it a priori and force it on others.
>> 
>> -rob
>> 
>> 
>> 
>> On Sat, Oct 1, 2022 at 1:39 PM Ian Lance Taylor > > wrote:
>> On Fri, Sep 30, 2022 at 7:32 AM Robert Engels > > wrote:
>> >
>> > Very interesting article came out recently. 
>> > https://www.infoq.com/articles/java-virtual-threads/ 
>> >  and it has 
>> > implications for the Go context discussion and the author makes a very 
>> > good case as to why using the thread local to hold the context - rather 
>> > than coloring every method in the chain is a better approach. If the 
>> > “virtual thread aka Go routine” is extremely cheap to create you are far 
>> > better off creating one per request than pooling - in fact pooling becomes 
>> > an anti pattern. If you are creating one per request then the 
>> > thread/routine becomes the context that is required. No need for a 
>> > distinct Context to be passed to every method.
>> 
>> I didn't read the article (sorry).
>> 
>> In a network server a Go context is normally specific to, and

Re: [go-nuts] Go routine context

2022-10-01 Thread Bakul Shah

I did a quick read. Virtual threads seems much *closer* to goroutines and they 
suggest people "unlearn" the overuse of thread local storage (TLS)! The thread 
pooling they talk about is to avoid the much higher thread creation time -- not 
a problem in Go.

> On Sep 30, 2022, at 9:08 PM, Rob Pike  wrote:
> 
> Like Ian, I have not read this paper, but I take it as a tenet that it is 
> better to keep goroutines anonymous and state-free, and not to bind any 
> particular calculation or data set to one thread of control as part of the 
> programming model. If you want to do that, sure, go for it, but it's far too 
> restrictive to demand it a priori and force it on others.
> 

-- 
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/F57252D8-54C2-468B-ACDE-6B7B42653B0D%40iitbombay.org.

Re: [go-nuts] Is Go a security malware risk?

2022-08-23 Thread Bakul Shah

Doesn't this article in fact argue that it is the *security teams* that have to 
get smarter about what kind of threads they will be faced with and figure out 
how to deal with them?

> On Aug 22, 2022, at 6:15 AM, 'Gopher-Insane' via golang-nuts 
>  wrote:
> 
> Hi
> 
> So our security team has raised a concern with Go and malware. The link that 
> was sent to me was 
> https://securityboulevard.com/2021/09/behavior-based-detection-can-stop-exotic-malware/
>  
> .
>  
> I reached out to Bill Kennedy on Twitter who disagreed that Go was a problem. 
> Said it was worth posting here to hear people's thoughts. 
> 
> 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/ed1966c2-675b-4030-911b-7fa618291985n%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/19FE5FF1-C971-4984-9D37-3C9581BDFE9B%40iitbombay.org.

Re: [go-nuts] Elementary Question About Calling Functions in Different Packages

2022-06-11 Thread Bakul Shah

On Jun 10, 2022, at 8:47 PM, jlfo...@berkeley.edu  
wrote:
> 
> One hack solution I came up with to break cycles when Package A depends on 
> Package B which depends on Package A is to
> create a symbolic link in Package A to the file(s) in Package B that 
> contain(s) the resources needed by Package A. Then Package A
> wouldn't be dependent on Package B anymore, and the cycle will  be broken. (I 
> just thought of this so I'm not 100% sure it will work
> until I try it).

You can factor out the mutually dependent functions in a separate package. For 
example if p1.P calls p2.P and p2.P calls p1.P,
create package p3, move p1.P and p2.P into p3 and rename them to p3.P1P and 
p3.P2P respectively.

> To tell the truth, the requirement that all files in a package be in the same 
> directory will probably cause the most misery. The program I'm
> trying to port has so many subdirectories containing so many files that this 
> will be a big problem. I'm thinking now that I'll have to move all the files
> in a package tree to the top level directory, and use a naming scheme so that 
> I can see which subdirectory each file came from.

You can start by simply treating each subdir as a package and then once things 
start working, refactor everything. The key is to either do refactoring up 
front or after you have a working, testable implementation, even if imperfect.

Another alternative is figure out major subsystems and data structures and 
create packages around them, adding many tests so that you can test each 
package in isolation.

Yet another alternative is to simply treat the existing app as a *reference* 
and nothing more. That is, rebuild your app in Go from scratch, simply based on 
the input/output behavior of the original app. But if the app is large and 
complex this may not be the best option. On the other hand I wouldn't want to 
convert a large and complex app to a different language, unless it can be 
broken up in smaller pieces relatively cleanly.

-- 
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/7AB0D4AB-F517-431E-822E-8647C12ECB9A%40iitbombay.org.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

2022-05-08 Thread Bakul Shah

On May 7, 2022, at 1:24 PM, Constantine Vassilev  wrote:
> 
> I need to write a program that reads STDIN and should output every line that 
> contains a search word "test" to STDOUT. 
> 
> How I can test that considering the problem is a line can be 100s of MB long 
> (\n is line end) and tens of MB info is passed to it.

What do you mean by "tens of MB info"? Do you mean the search
string can be tens of MB long or something else? Is the search
string really "test" or can it be anything? Can it be a regular
expression? Describing a problem clearly and accurately is half
the battle.

Anyway, think about what you would have to do if lines were so long
they *didn't* fit in memory! [Alternatively think what you would
have to do on a PDP11!]

-- 
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/4182031A-F9D6-4D10-9709-78FA4DFCE4CE%40iitbombay.org.

Re: [go-nuts] Add comparisons to all types

2022-05-03 Thread Bakul Shah

On May 3, 2022, at 7:27 PM, Ian Lance Taylor  wrote:
> 
> Does a program like this print true or false?
> 
> func F() func() int { return func() int { return 0 } }
> func G() { fmt.Println(F() == F()) }
> 
> What about a program like this:
> 
> func H(i int) func() *int { return func() *int { return  } }
> func J() { fmt.Println(H(0) == H(1)) }

Note that in Scheme eq? works for functions as one would expect.

> (define (f (lambda (x) x))
> (eq? f f)) => #t
> (define g f)
> (eq? f g) => #t

But
> (eq? f (lambda (x) x)) => #f
> (define g (lambda () (lambda (x) x)))
> (eq? (g) (g)) => #f

One can make the case that each closure would be a fresh instance.
This is more clear with a slightly more complex version:

(define (counter m) (let ((n m) (lambda () (set! n (+ n 1)) n))

And equal? is unspecified in the Scheme RnRS but would typically implemented
to return #f.

> (equal? (lambda (x) x) (lambda (x) x)) => #f

Technically (lambda (x) x) & (lambda (y) y) behave identically but
proving the more general case of this in even an interpreter would
be hard to impossible.

Go pretty much has the same considerations (but for a more complex
data model).

-- 
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/2E7C1835-40C5-4FF3-BB7B-D32A71EE89EC%40iitbombay.org.

Re: [go-nuts] Tacit Golang?

2022-04-02 Thread Bakul Shah

If I understand you right, you seem to want to use "<-" as the "compose" higher 
order function but as an infix operator. That is, instead of "value := 
F(G(args...))", you want to be able to write "value := (F <- G)(args...)". 
Further, "F <- G <- H" means "F <- (G <- H)". F, G  are functions such that 
F(G(H(args...)) is a valid expression, if args... is valid.

My gut instinct says Go is the wrong language to extend for tacit programming. 
If you look at existing code, my guess is you won't find very many instances of 
code that can be mapped to tacit programming. So low "bang for the buck". 
Second the optimization that you talk about in point C. is likely not very 
important or even meaningful. Typically it is the *called* function that pops 
the stack, not the caller and unless you can inline things like (F<-G<-H) you 
can't collapse three pops into one. Third, in Go you can't short circuit error 
returns. Thus if H can return an error, you can't use it in a pipeline! You 
have to handle the error at the call site of H. Ideally one (or at least *I*) 
would want something like F(G(H(...)) to return to the call site of F with an 
erorr, without executing F or G in case H fails.

> On Apr 1, 2022, at 3:41 PM, Sam Hughes  wrote:
> 
> Point-free programming, or "tacit programming",  is a convention that 
> highlights the intent without syntactic noise. 
> 
> For those unfamiliar, wikipedia: 
> https://en.wikipedia.org/wiki/Tacit_programming
> 
> I want better function composition. "Write a helper function to route values 
> out to values in, like a normal person." Sure, but who needs Go when you have 
> C, eh? A tacit sugaring merely provides a lexically distinctive means to 
> indicate the intent that function f0 should be called with the return value 
> of f1, and f1 of f2, and so on, with reduced syntax.
> 
> There are a couple layers here, there's an easy win, a possible next step, 
> and well, madness.
> 
> A. Go uses a thin-arrow, "<" + "-", as a receive/send operator and to signify 
> directionality of a channel. This same operator could be used like so, "c := 
> a <- b()" to assert the following:
> 1. Token "a" resolves to a function pointer
> 2. Token "b" returns none, one, or many values, such that "a(b())" is 
> legal.
> 3. Token "c" can legally be assigned the value of the desugared 
> expression.
> This suggestion imposes ambiguity between the meaning of "(chan 
> int)(x)<-y(z)" and "(func(int)int)(x)<-y(z)", and I have chaotic intuitions 
> about the meaning of "(func(int)int)(x) <- (chan int)(y)", or even 
> "(func(int)int)(x) <- (chan int)(y) <- z", but x(<-y) is clearly 
> (func[T](T)T)(x)(<-(chan[T] T)(y)). A minimally disruptive solution, then, is 
> to assert that the tip of such a tacit chain must be a full-syntax 
> invokation, e.g. for "f0 <-...f <- ?", only "f(...)" is valid. This 
> means expressions like "c0 <- f0 <- f1(f2 <-f3(<-c1))" are unambiguous 
> without a mountain of ellipses.
> 
> B. At cost of introducing a new concept for Go entirely, it would be 
> convenient to declare a function as "f0 := f1 <- f2 <- f3", resolving as 
> suggested by the statement: "reflect.TypeOf(f0) == 
> reflect.FuncOf([]reflect.Type{reflect.TypeOf(f3).In(0), ..}, 
> []reflect.Type{reflect.TypeOf(f1).Out(0), ...})". The straightforward 
> path to implementation would resolve that naively, as suggested by the 
> following: "f0 := func[T handWaving.inT, U handWaving.outT](a... T) (...U) 
> {return f1(f2(f3(a...)))}". A statement like "go f0 <- f1 <-f2 <- f3", 
> assuming "go func[T handWaving.inT](a...T) {f0(f3(a...));}" is legal, would 
> be an attractive pattern.
> 
> C. Naively, point B suggests that the functions thus concatenated could be 
> assembled as to preallocate the stack for the entire concatenation, omitting 
> the allocations and moves/copies between function calls, and rather writing 
> the return values to the stack for the predecessor function, by analogy, like 
> a reverse closure or a heterogenous recursion. For the example "f0 := f1 <- 
> f2 <- f3", because I expect that statement to only be legal if 
> "f1(f2(f3(..args..)))" is legal, the out-signature of f3 is 
> assignment-compatible with the in-signature of f2, and f2 to f1. Concerns 
> such as an element in the concatenation being recursive, blocking, or 
> corrupting only apply to the function at stack-head; pre-allocating even a 
> potentially large stack exposes only risk shared with allocating the same 
> stack progressively, but with lower instructional segmentation. A possible 
> but unlikely edge-case, if for some reason, a generic function cannot be 
> appropriately stenciled, the optimization being suggested might only 
> partially be applied, or else not applied at all. 
> 
> Ellipses are basically universal for "I give you control, but I expect it 
> back". Loops don't give up control, rather push it on a swing like a child. 
> Go-func commissions an agent, expecting no control. Point A would

Re: [go-nuts] Why, oh why, do people do this? Things that annoy me in Go code.

2022-03-07 Thread Bakul Shah

GoBOL, anyone?

> On Mar 7, 2022, at 2:20 PM, Rob Pike  wrote:
> 
> It could have been
> 
> interface 
> UnreceivedMasterOrdersInterfaceThatCanBeUsedToCallGetUnreceivedByProductsWarehouseAndCompany
> 
> Seriously, though, your example isn't even on the same planet as some
> of the examples I've seen. (Neither is my parody.)
> 
> Sympathies.
> 
> -rob
> 
> On Tue, Mar 8, 2022 at 7:49 AM Rudolf Martincsek  wrote:
>> 
>> Latest interface my colleagues wrote (it's PHP)
>> ---
>> interface UnreceivedMasterOrdersInterface
>> {
>>   public function getUnreceivedByProductsWarehouseAndCompany(array 
>> $productIds, int $warehouseId, int $companyId): array;
>> }
>> ---
>> There is interest to switch to Go for some of the stuff we write, but I 
>> decided to leave before that happens. I like programming in Go for myself, 
>> and I don't want to start hating it because of nonsense like this.
>> 
>> 
>> On Wednesday, February 2, 2022 at 8:51:54 AM UTC+2 Amnon wrote:
>>> 
>>> Idiomatic naming in Go is one of the hardest things to communicate.
>>> Everyone seems to bring the idioms from previous languages. Dave Cheney 
>>> writes about
>>> "Lengthy bureaucratic names carry a low amount of signal compared to their 
>>> weight on the page".
>>> Identifiers are not sentences or stand alone stories. They are the the 
>>> basic building blocks for our code.
>>> We have all seen code infected by these names - long names leading to long 
>>> lines of code,
>>> and verbose walls of dense text, repetitive and hard to read.
>>> 
>>> I always encourage people to read https://go.dev/doc/effective_go#names
>>> to study the Go standard library, and develop a feel of what Go code should 
>>> read like.
>>> 
 
 
>> --
>> 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/00dec58d-421a-4b86-9c15-6533fc648974n%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/CAOXNBZQ9FvDDusTGkRZdJbUNOMCL%2B8Td2QW_7KYQK45CmEUfxA%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/2CC7FEE7-09B5-4B1D-8976-5EC82DDCC978%40iitbombay.org.

Re: [go-nuts] Data Structure for String Interning?

2022-01-09 Thread Bakul Shah



> On Jan 9, 2022, at 6:15 PM, burak serdar  wrote:
> 
> I think the question is "why do you want to intern strings". The solution can 
> be different for different use cases.

Indeed. This is a given! Such tricks should only be tried if the benefits
outweigh the cost, as per profiling expected use cases for your program.

[Aside:
Though it is unfortunate that most (all?) programming languages
do not make it easy to try out alternative data structures. As an
example, try replacing processing an array of structs with a struct
of arrays, with each struct member stored in a different array!
Row oriented vs Column oriented processing. 
]

> I work with large Json files where keys are repeated, and the keys are long 
> strings (URLs) so using a map[string]string to intern the keys makes a lot of 
> sense. For serialization, the same idea is used to compress large data using 
> string tables: a []string holds all unique strings, and references to those 
> strings are represented using uint32 indexes. For the example where you 
> intern words, you might even consider a single []byte containing all the 
> words concatenated, with a custom string representation containing uint32 
> offset and length. This may or may not be faster than the map implementation, 
> but it will occupy less space, but with a single large object in memory.
> 
> On Sun, Jan 9, 2022 at 5:35 PM Bakul Shah  <mailto:ba...@iitbombay.org>> wrote:
> The string header will be 16 bytes on 64bit word size machines.
> If most of the words are much shorter, interning won’t buy you
> much. For applications where you *know* all the words are short,
> and the total string space won’t exceed 4GB, you can try other
> alternatives. For instance if the max length of any word is 16 bytes,
> create 16 string tables. Then the ‘interned string’ type is a 4 byte
> index, with the bottom 4 bits indicating the length as well as which
> table to index! A table for N byte words stores one copy of each
> unique word and in consecutive slots on N bytes. Given that on modern
> machines even though memory can be plentiful, memory access is slow
> & computing is fast, this can win. You will also need a possibly unsafe
> String func. that doesn’t allocate string data space. You can even allow
> an overflow table if longer words are not common. And you can allow
> many more unique words by extending the interned string type to 8
> bytes.
> 
>> On Jan 9, 2022, at 3:07 PM, burak serdar > <mailto:bser...@computer.org>> wrote:
>> 
>> 
>> Note that a with a map[string]string, the code:
>> 
>> m[s]=s
>> 
>> The contents of the string s are not duplicated, only the string header s 
>> is. 
>> 
>> On Sun, Jan 9, 2022 at 3:52 PM jlfo...@berkeley.edu 
>> <mailto:jlfo...@berkeley.edu> > <mailto:jlforr...@berkeley.edu>> wrote:
>> I'm aware of Artem Krylysov's idea for string interning published on
>> https://artem.krylysov.com/blog/2018/12/12/string-interning-in-go/ 
>> <https://artem.krylysov.com/blog/2018/12/12/string-interning-in-go/>
>> 
>> If I understand it correctly, each string is stored twice in a map, once as
>> a key and once as a value. That means that words that only appear once in
>> his example of string interning the words in the novel 1984 are 100% 
>> inefficient
>> in terms of storage. Words that appear twice are neutral. The advantage of 
>> his
>> approach only appears for words that appear three or more times.
>> 
>> I'm wondering if there's a map-like data structure that would store a string
>> as the key, and the address of the key as the value. I'm aware that a 
>> standard
>> Go map can't be used for this because its components might be moved around
>> while a program is running so taking the address of the key would be 
>> dangerous,
>> which is why it isn't allowed.
>> 
>> This came up because I profiled a run of an app I'm working on that
>> processed 12518 strings, of which 9810 appeared 2 or fewer times. Krylysov's
>> approach would only be marginally useful for this app.
>> 
>> The data structure I'm looking for would always be at least neutral, and 
>> would start
>> showing a benefit when a word appears twice.
>> 
>> Does anybody know of such a data structure?
>> 
>> Cordially,
>> Jon Forrest
>> 
>> -- 
>> 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

Re: [go-nuts] Data Structure for String Interning?

2022-01-09 Thread Bakul Shah

The string header will be 16 bytes on 64bit word size machines.
If most of the words are much shorter, interning won’t buy you
much. For applications where you *know* all the words are short,
and the total string space won’t exceed 4GB, you can try other
alternatives. For instance if the max length of any word is 16 bytes,
create 16 string tables. Then the ‘interned string’ type is a 4 byte
index, with the bottom 4 bits indicating the length as well as which
table to index! A table for N byte words stores one copy of each
unique word and in consecutive slots on N bytes. Given that on modern
machines even though memory can be plentiful, memory access is slow
& computing is fast, this can win. You will also need a possibly unsafe
String func. that doesn’t allocate string data space. You can even allow
an overflow table if longer words are not common. And you can allow
many more unique words by extending the interned string type to 8
bytes.

> On Jan 9, 2022, at 3:07 PM, burak serdar  wrote:
> 
> 
> Note that a with a map[string]string, the code:
> 
> m[s]=s
> 
> The contents of the string s are not duplicated, only the string header s is. 
> 
>> On Sun, Jan 9, 2022 at 3:52 PM jlfo...@berkeley.edu  
>> wrote:
>> I'm aware of Artem Krylysov's idea for string interning published on
>> https://artem.krylysov.com/blog/2018/12/12/string-interning-in-go/
>> 
>> If I understand it correctly, each string is stored twice in a map, once as
>> a key and once as a value. That means that words that only appear once in
>> his example of string interning the words in the novel 1984 are 100% 
>> inefficient
>> in terms of storage. Words that appear twice are neutral. The advantage of 
>> his
>> approach only appears for words that appear three or more times.
>> 
>> I'm wondering if there's a map-like data structure that would store a string
>> as the key, and the address of the key as the value. I'm aware that a 
>> standard
>> Go map can't be used for this because its components might be moved around
>> while a program is running so taking the address of the key would be 
>> dangerous,
>> which is why it isn't allowed.
>> 
>> This came up because I profiled a run of an app I'm working on that
>> processed 12518 strings, of which 9810 appeared 2 or fewer times. Krylysov's
>> approach would only be marginally useful for this app.
>> 
>> The data structure I'm looking for would always be at least neutral, and 
>> would start
>> showing a benefit when a word appears twice.
>> 
>> Does anybody know of such a data structure?
>> 
>> Cordially,
>> Jon Forrest
>> -- 
>> 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/36684584-11eb-4bc0-a436-4906d523c8ban%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/CAMV2RqodPp7kye6%3D5PH0NHha%2BwQC4mqfotipoutm4aeL1EK0Fw%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/F45BFAB2-315B-479A-A7BA-04BC61657AB7%40iitbombay.org.

Re: [go-nuts] Managing perpetually running goroutines

2021-09-01 Thread Bakul Shah

Suggest you look at https://go.dev/blog/pipelines 
And check out the two videos recommended at the end of this article.
Lots of interesting articles in the blog for you to chew on!

-- Bakul

> On Sep 1, 2021, at 2:55 PM, sanyia.said...@gmail.com wrote:
> 
> Thanks Bryan, especially for the code example.
> 
> Would using a sync.WaitGroup in place of the `done` channel in your example 
> be overkill? Just exploring what’s possible here for my own education.
>  
> From: 'Bryan C. Mills' via golang-nuts 
> Sent: 31 August 2021 20:22
> To: golang-nuts 
> Subject: Re: [go-nuts] Managing perpetually running goroutines
>  
> For the specific case of managing long-running polling- or pubsub-based 
> tasks, I would suggest basically the same pattern that others on the thread 
> have already given: use a `sync.Map` to associate each task ID with a small 
> struct containing a `context.CancelFunc` and a channel that can be used to 
> confirm when the task has actually stopped 
> (https://play.golang.org/p/Gq3SXuPFDvi).
>  
> That way you can have the invariant that after a successful call to Stop, the 
> worker has completely finished all of its work. That property is extremely 
> useful, for example, in writing tests and benchmarks for your implementation: 
> if you can guarantee that the workers have actually stopped by the time Stop 
> returns, your tests can detect unexpected deadlocks and your benchmarks can 
> measure a controlled, well-defined amount of work.
>  
>  
>  
>  
> On Monday, August 30, 2021 at 7:52:59 AM UTC-4 Brian Candler wrote:
> For that case, I'd suggest you pass a channel to each worker.  It can either 
> close the channel, or send a specific message down it, to indicate its 
> termination.
>  
> This may also be an X-Y problem.  Generally speaking, "worker pools" are an 
> anti-pattern in Go.  The startup and termination overhead of a goroutine is 
> so tiny that often it's better just to start a goroutine when there's work to 
> be done, and let it run to completion.  The other reason you might want to 
> have a worker pool is to limit concurrency, but there are better ways to do 
> that in Go: e.g. you can have a buffered channel with N slots, which the 
> goroutine writes to before starting work and reads from when it's finished. 
> That will limit your concurrency to N tasks.
>  
> Bryan C Mills discusses this in detail in this excellent video on "Rethinking 
> Classical Concurrency Patterns":
> https://www.youtube.com/watch?v=5zXAHh5tJqQ 
> 
> It took me several views with pauses to fully understand it, but it was worth 
> the effort :-)
>  
> On Monday, 30 August 2021 at 12:29:26 UTC+1 sansaid wrote:
> Appreciated, thanks Brian and Ian.
>  
> On the subject of sync.WaitGroups, I haven't tackled this yet for my use 
> case, but will use the opportunity to brainstorm some options, if that's 
> okay. I want to be able to terminate each worker independently of others 
> (i.e. close on worker, wait for it to finish its tasks, but allow other 
> workers to run if they haven't been signalled to stop). Should I create a 
> wait group per worker and store that in a map? This sounds bloated to me, 
> especially since it's always going to be a wait group of 1, but I haven't 
> come across better alternatives yet (relatively new to concurrency myself).
>  
> If that's too broad a question, can come back once I've explored some options.
>  
> On Mon, 30 Aug 2021, 12:20 Brian Candler,  wrote:
> Also: you can use the same context for all the workers (if that's 
> appropriate); or if you want each worker to have a different context, you can 
> make those contexts children of the same top-level context.  In that case, 
> you only need to cancel one context and all the workers will stop, without 
> having to keep a map of them.
>  
> Do bear in mind that you may wish to wait for the workers to finish what 
> they're currently doing, before the program exits.  One way to do that is 
> with a sync.WaitGroup, which you increment before starting each worker, and 
> each worker decrements just before it terminates.  Then in your main program 
> you wait on the WaitGroup.
>  
> Typical pattern: https://play.golang.org/p/51oy7ySbL4T 
> 
>  
> On Monday, 30 August 2021 at 10:01:08 UTC+1 Ian Davis wrote:
>  
> On Sun, 29 Aug 2021, at 10:45 PM, sansaid wrote:
> Hello,
>  
> Does anybody know of some reference code or common patterns I can use to keep 
> track of worker goroutines? For context, I want a user to be able to issue a 
> "stop" command using a CLI tool which will prompt my server to gracefully 
> terminate one of my workers. 
>  
> For example, when a user issues a "start" command through a CLI tool, this 
> will signal my server to spawn a goroutine that perpetually runs and polls an 
> HTTP endpoint until a user initiates a "stop" command.

Re: [go-nuts] Golang language specification Document: Composite Literals example is not understandable

2021-06-22 Thread Bakul Shah

If you are familiar with C99’s designated initializers, this is similar but 
less general
and less confusing.

> On Jun 22, 2021, at 8:40 AM, Vaibhav Maurya  wrote:
> Hi,
> 
> Please help me to understand the following syntax mentioned in the Golang 
> language specification document.
> 
> https://golang.org/ref/spec#Composite_literals
> 
> following is the search string for CTRL + F
> // vowels[ch] is true if ch is a vowel \
> 
> Following declaration and initialization is confusing.
> vowels := [128]bool{'a': true, 'e': true, 'i': true, 'o': true, 'u': true, 
> 'y': true}
> 
> Here one can see the vowels is an array. Where in the array initialization 
> syntax, there is a key value pair. I believe bool is the primitive type, so 
> the array values should be either true or false.
> Why there are key value pair separated by colon in the initialization.
> -- 
> 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/83571d7c-7dee-47f3-b105-4286320e88d6n%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/E7DEE768-5F85-4AE2-BDBD-830E8DBEA199%40iitbombay.org.

Re: [go-nuts] Representing Optional/Variant Types Idiomatically (or not)

2021-06-17 Thread Bakul Shah

On Jun 17, 2021, at 1:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Thu, Jun 17, 2021 at 9:43 AM Joshua  wrote:
> 
>> 1) I'm modelling a data type which has a field which may or may not be
>>   there, would most Gophers reach for a pointer here, and use `nil' to
>>   represent a missing value?
> 
> That's the usual approach seen in the wild and IMO often the wrong one.
> 
> Unless the size of the field's type is big, I'd suggest just a plain
> field and a boolean value that represents the "present/valid"
> information.

This can get error prone as you may forget to update the validity field
and the error may not be caught easily.  And painful if you have more
than one optional field. Now you need to invent more names or use
longer names (foo_valid). The pointer alternative will fail more obviously
if you mess up!

> 
> Less GC pressure, improved cache locality.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-XGP2edWe1b13kpE4PhdFdCsJWGk79z8ngEpj19ycwmxQ%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/1CBA5F6B-2570-44A4-A6F0-26679FA1A43F%40iitbombay.org.

Re: [go-nuts] Still "missing" priority or ordered select in go?

2021-05-05 Thread Bakul Shah

On May 5, 2021, at 9:55 AM, Øyvind Teig  wrote:
> 
> Here is my cognitive test case. It is not 100% realistic, but it's just to 
> convey my point:
> hiPri is a disconnect message of a smoke detetector. loPri is a fire alarm. 
> If the disconnect hiPri is activated before (1 sec to 1 ns) or simulatenously 
> (same polling of "hw pins") as the alarm loPri there should be no alarm being 
> sent to the fire department. No emergency fire trucks. Not ever. There should 
> not be any case of some low probability where this may happen. However, if 
> the hiPri disconnect message was activated after the alarm, then it was too 
> late, and the alarm will go off. (Disconnect was because we knew that there 
> was going to be an alarm since we were doing something, and we explicitly did 
> not want the fire trucks to come)

Imagine that the latency between the device detecting a disconnect
signal and a user hitting a disconnect button is D ns while the fire
detection latency is F ns. So if D > F the device would raise the
alarm even if you implement it all in hardware! The only difference
between a Go implementation vs a hardware  one is the window size.
If you want to make it minimize it, Go is not the right solution.
For that, in H/W you'd probably *gate* the alarm line to the fire
department with the disconnect signal! But even so there is a small
window.

I think if you have a mix of hard and soft real time requirements,
where soft RT tasks can take a long time, you'd likely want priority
scheduling with preemption. IMHO Go is the wrong choice for that.

-- 
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/73C1590D-F77A-4613-B522-3DFE1A3FA0BE%40iitbombay.org.

Re: [go-nuts] rationale for math.Max(1, math.NaN()) => math.NaN()?

2021-04-27 Thread Bakul Shah

>From the wikipedia article:

There are differences of opinion about the proper definition for the result of 
a numeric function  that receives a 
quiet NaN as input. One view is that the NaN should propagate to the output of 
the function in all cases to propagate the indication of an error. Another 
view, and the one taken by the ISO C99  and 
IEEE 754-2008  standards 
in general, is that if the function has multiple arguments and the output is 
uniquely determined by all the non-NaN inputs (including infinity), then that 
value should be the result.

Should Go be updated to follow IEEE 754-2008? [I assume currently it is 
following IEEE 754]

-- Bakul

> On Apr 26, 2021, at 11:28 PM, christoph...@gmail.com 
>  wrote:
> 
> It seam that C is wrong on this one and Go is right. The rationale is that a 
> NaN must propagate through operations so that we can detect problems (avoid 
> silent NaNs). See https://en.wikipedia.org/wiki/NaN 
> 
> 
> Thus any operation involving a NaN must return an NaN and this includes Max 
> and Min. 
>  
> Le jeudi 22 avril 2021 à 12:43:23 UTC+2, jesper.lou...@gmail.com a écrit :
> On Thu, Apr 22, 2021 at 11:54 AM 'Dan Kortschak' via golang-nuts 
>  > wrote:
> 
> Does anyone know the reason for this? (Looking through other languages,
> the situation in general seems to be a mess).
> 
> 
> I looked at OCaml, which provides both variants:
> 
> Float.max : float -> float -> float
> Float.max_num : float -> float -> float
> 
> The `max` function includes NaNs in the computation, while `max_num` omits 
> them. Another important treatment the documentation mentions is `max -0.0 
> +0.0`.
> 
> I also looked at Matlab and R. They essentially provide ways to either 
> include the NaN or omit it from the computation, usually when you have a 
> vector of numbers where some of the numbers are unknown. I.e., they take 
> extra (optional) flags to their functions which tells you how to treat NaN 
> values.
> 
> The "pure" solution is clearly the one where NaN's yield a NaN. It is 
> isomorphic to a Monoid based on optional values with the NaN forming the 
> unknown element, often called the option-monoid or the maybe-monoid. Or said 
> otherwise: for any type a, where a is a monoid, so is 'option a':
> 
> forall a. Monoid a => Monoid (Option a)
> 
> Since the max function itself is a monoid with the neutral element taken as 
> the minimal value, -inf, we can thus "lift" NaN values on top and still have 
> some mathematical consistency.
> 
> But if you have an array of values, where some of them can be NaN, it is 
> probably smart to provide a function which filters the array of NaN values 
> and computes the remaining values. R provides the function `na.omit(..)` for 
> this. So do option types in languages such as OCaml or Haskell. Here, we are 
> not that concerned about what is sound from a formal point of view, but more 
> concerned with data cleanup before we start using the formality.
> 
> Max of two values is a special case. The generalized version takes an 
> array/vector of values and provides the maximum in the structure.
> 
> All of this leads me to conclude you probably want both variants in the end. 
> In some situations, it is better to include NaN values in the computation, 
> and in other situations, the right move is to omit/exclude them.
> 
> 
> 
> -- 
> 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/9950a06b-1222-4543-b979-763f37516e2an%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/CEEB3353-7441-4D50-84FA-61E6EFCC83F4%40iitbombay.org.

Re: [go-nuts] [ANN] star-tex: a Go engine for TeX

2021-02-21 Thread Bakul Shah

On Feb 21, 2021, at 9:14 AM, Sebastien Binet  wrote:
> 
> On Sun Feb 21, 2021 at 17:46 CET, Patrick wrote:
>> Hi Sebastien,
>> 
>> that was a manual translation of the web file.
>> My plan was to do more than that, ... TeX is such a beast.
> 
> yeah... "how hard would it be to translate ~20k lines of C/C++ code (or
> 6k lines of obfuscated Pascal code) into a set of nicely structured Go
> packages" ? :)


Aren't you supposed to read Knuth's TeX: The Program book instead of
the 6k lines of Pascal?! 

Also, I don't understand why anyone would want to do that.

> 
> my initial strategy to have something working in a mixture of Go and
> C/C++ (I am in the middle of getting rid of the C++ part), is OK to get
> some PDFs out of the gate, but I think I need to invest in the tooling
> to do the automatic web->Go translation. (either web->Pascal->Go or
> web->C->Go.)

Doesn't web2c directly translate the web sources to C? 

> tex.web doesn't change too much nor too often, but 3.141592653 was just
> "released" after I had started my C/C++->Go migration (bummer), so it
> does happen.


-- 
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/B8226003-585A-454C-8712-E150FB3D04DF%40iitbombay.org.

Re: [go-nuts] Advice, please

2021-01-18 Thread Bakul Shah

On Jan 18, 2021, at 4:39 AM, Kevin Chadwick  wrote:
> 
> On 1/17/21 4:46 PM, Bakul Shah wrote:
>> I’d be tempted to just use C for this. That is, generate C code from a 
>> register
>> level description of your N simulation cores and run that. That is more or 
>> less
>> what “cycle based” verilog simulators (used to) do. The code gen can also 
>> split
>> it M ways to run on M physical cores. You can also generate optimal
>> synchronization code.
>> 
>> With linked lists you’re wasting half of the memory bandwidth and potentially
>> the cache. Your # of elements are not going to change so a linked list 
>> doesn’t
>> buy you anything. An array is ideal from a performance PoV.
> 
> Potentially forgive me and ignore this message if inappropriate as I haven't
> been paying close attention to this thread at all really.
> 
> However, it strikes me that arrays are perfectly usable in GO. Similarly to 
> how
> you might use a global array with tinygo to ensure memory usage limits are not
> breached. What is the issue of using an array in Go? Even a global one, *IF*
> suited to the task at hand and dishing the work out to workers with a scheme a
> little more complex than odd, even etc. as required?

Go arrays are perfectly usable. My comment had more to do with the fact that
you'd just have a fixed number of threads and if synchronization using channels
is not fast enough, you'd have to roll your own, in which case Go doesn't
really buy you much. I'd just keep the simulator code as a separate process
that does nothing but simulation and have it communicate with a separate
program that does visualization, logging etc. which can be in Go. Pete Wilson
in his response said that simulated cores are already generated functions in C
so this is not a big step. I'd just have the code generator generate the whole
simulator or something like it. Just different tradeoffs to consider.

-- 
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/FF9E41C6-1277-428E-8464-54697359858B%40iitbombay.org.

Re: [go-nuts] Advice, please

2021-01-17 Thread Bakul Shah

I’d be tempted to just use C for this. That is, generate C code from a register 
level description of your N simulation cores and run that. That is more or less 
what “cycle based” verilog simulators (used to) do. The code gen can also split 
it M ways to run on M physical cores. You can also generate optimal 
synchronization code.

With linked lists you’re wasting half of the memory bandwidth and potentially 
the cache. Your # of elements are not going to change so a linked list doesn’t 
buy you anything. An array is ideal from a performance PoV.

> On Jan 17, 2021, at 7:49 AM, Pete Wilson  wrote:
> That’s exactly the plan.
> 
> The idea is to simulate  perhaps the workload of a complete chiplet. That 
> might be (assuming no SIMD in the processors to keep the example light) 2K 
> cores. Each worklet is perhaps 25-50 nsec (worklet = work done for one core) 
> for each simulated core
> 
> The simplest mechanism is probably that on finishing work, every worker sends 
> a message to main; when it’s got all the messages, it sends a message to each 
> of the workers. Nice and simple. But it seems as though a channel 
> communication is of the order of 100ns, so I’m eating 200nsec per phase 
> change in each worker
> 
> With 10 executing cores and 2K simulated cores, we get to do around 200 
> worklets per phase per executing core. At 25ns per worklet that’s 5 
> microseconds of work per worker, and losing 200nsec out of that will still 
> let the thing scale reasonably to some useful number of cores. 
> 
> But tools are more useful if they’re relative broad-spectrum. If I want to 
> have 20 worklets per core per phase (running a simulation on a subset of the 
> system, to gain simulation speed), I now am using ~ 200ns out of 500 ns of 
> work, which is not a hugely scalable number at all. Probably it’d run slower 
> than a standard single core sequential implementation regardless of the 
> number of cores, so not a Big Win
> 
> Were the runtime.Unique() function to exist (a hypothetical scheduler call 
> that, for some number of goroutines and cores, allows a goroutine to declare 
> that it should be the sole workload for a core; limited to a fairly large 
> subset of available cores) I could spinloop on an atomic load, emulating 
> waitgroup/barrier behaviour without any scheduler involvement and with times 
> closer to the 10ns level (when worklet path lengths  were well-balanced)
> 
> I’d also welcome the news that under useful circumstances channel 
> communication is only (say) 20ns. That’d simplify things beauteously. (All ns 
> measured on a ~3GHz Core i7 of 2018)
> 
> [Historical Note: When I were a young lad, I wrote quite a bit of stuff in 
> occam, so channel-y stuff is lapsed second nature - channels just work - and 
> all this building barrier stuff is terribly unnatural. So my instincts are 
> (were?) good, but platform performance doesn’t seem to want to play along]
> 
>> On Jan 17, 2021, at 9:21 AM, Robert Engels  wrote:
>> 
>> If there is very little work to be done - then you have N “threads” do M 
>> partitioned work. If M is 10x N you’ve decimated the synchronization cost. 
> 
> 
> 
> WARNING / LEGAL TEXT: This message is intended only for the use of the 
> individual or entity to which it is addressed and may contain information 
> which is privileged, confidential, proprietary, or exempt from disclosure 
> under applicable law. If you are not the intended recipient or the person 
> responsible for delivering the message to the intended recipient, you are 
> strictly prohibited from disclosing, distributing, copying, or in any way 
> using this message. If you have received this communication in error, please 
> notify the sender and destroy and delete any copies you may have received. 
> 
> http://www.bsc.es/disclaimer 
> 
> 
> 
> 
> 
> 
> WARNING / LEGAL TEXT: This message is intended only for the use of the 
> individual or entity to which it is addressed and may contain information 
> which is privileged, confidential, proprietary, or exempt from disclosure 
> under applicable law. If you are not the intended recipient or the person 
> responsible for delivering the message to the intended recipient, you are 
> strictly prohibited from disclosing, distributing, copying, or in any way 
> using this message. If you have received this communication in error, please 
> notify the sender and destroy and delete any copies you may have received. 
> 
> http://www.bsc.es/disclaimer

-- 
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/BE0A5A72-2FF3-4FD5-8EC1-F2EB53532428%40iitbombay.org.

Re: [go-nuts] Advice, please

2021-01-16 Thread Bakul Shah

You may be better off maintaining two state *arrays*: one that has the current 
values as input and one for writing the computed outputs. At "negtive" clock 
edge you swap the arrays. Since the input array is never modified during the 
half clock cycle when you compute, you can divide it up in N concurrent 
computations, provided a given output cell is written by just one thread. So 
theen the synchronization point is when all the threads are done with they 
computing. That is when you swap I/O state arrays, advance the clock and 
unblock all the threads to compute again. You can do this with N+1 channels. 
The tricky part may be in partitioning the computation in more or less equal N 
parts.

> On Jan 13, 2021, at 4:21 PM, Peter Wilson  wrote:
> 
> Folks
> I have code in C which implements a form of discrete event simulator, but 
> optimised for a clocked system in which most objects accept input on the 
> positive edge of a simulated clock, do their appropriate internal 
> computations, and store the result internally. On the negative edge of the 
> clock, they each take their stored internal state and 'send' it on to the 
> appropriate destination object
> 
> This is modelled using a linked list of objects, each of which has a phase0 
> and phase1 function, and traversing the list twice per clock, calling the 
> appropriate function.
> 
> It all works fine. On a uniprocessor. If we have one processor object and one 
> memory object, with the processor implementing a standard instruction fetch 
> decode implement interpreted loop, and playing with simulated caches, reading 
> or writing on cache misses, we can get 20-30 MIPS on a Mac Mini. 
> 
> So since (much!) more performance is wanted, implementing this for a 
> multiprocessor seems a good idea. Especially since every computer and its dog 
> is multicore. Using go rather than C also sounds like a good idea.
> 
> So  the sketch of the go implementation is that I would have three threads - 
> main, t0, and t1. (more for a real system, but two suffices for explanation)
> - main sets stuff up, and t0 and t1 do the simulation work
> - main has to initialise, set up any needed synchronization mechanism, and 
> start t0 and t1
> - t0 and t1 wait until main says its ok, then both traverse all objects in 
> the list. t0 runs the function if it's an even numbered object, and t1 if 
> it's an odd-numbered. No mutation of state by concurrent threads.
> - main loops, as do t0 and t1; t0 and t1 signal that they've finished; when 
> they have, main tells them to start the next traversal
> 
> So, after a long ramble, given that I am happy to waste CPU time in busy 
> waits (rather than have the overhead of scheduling blocked goroutines), what 
> is the recommendation for the signalling mechanism when all is done in go and 
> everything's a goroutine, not a thread?
> 
> My guess is that creating specialist blocking 'barriers' using sync/atomic 
> (atomic.Operation seems to be around 4nsec on my Mac Mini) is the highest 
> performance mechanism. There's a dearth of performance information on channel 
> communication, waitgroup, mutex etc use, but those I have seen seem to 
> suggest that sending/receiving on a channel might be over the order of 
> 100nsec; since in C we iterate twice through the list in 30-40nsec, this is a 
> tad high (yes, fixeable by modeling a bigger system, but)
> 
> I know that premature optimisation is a bad thing, but I'd prefer to ask for 
> advice than try everything..
> 
> many thanks for any help
> 
> -- P
> 
> 
> 
> -- 
> 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/5a1d1ccb-26f4-4da0-94fb-679c201782dan%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/D71209D9-DBC5-4B56-85CF-79790DCD926B%40iitbombay.org.

Re: [go-nuts] Generics, please go away!

2020-12-25 Thread Bakul Shah

On Dec 25, 2020, at 8:48 AM, Henrik Johansson  wrote:
> 
> Both Java and C++ has benefited greatly from generics and most of their 
> respective communities wouldn't want them gone. I am pretty sure that's what 
> will happen with Go as well. Can we leave it now before we go from 
> "corruption" to whatever hyperbole is next?

As Simon Peyton Jones has said, static types have been the most *successful* 
program verification technique! The more your types can express what you want 
your programs to do, the more the compiler can check them for you (and reject 
bad programs upfront). If types can be made more expressive (such as with 
generics) *without* making programs more incomprehensible (and less fun) it is 
a win!

As for the "simplicity" argument, he simplicity of user programs should be 
considered even more important than that of the language. That is, can you 
express your programs simply (without having to build in the kitchen sink in 
the language)?

Clearly there are things such as printing/parsing, 
serialization/deserialization, copying, collections, counting elements, more 
general processing of collections, graph algorithms etc. that can benefit from 
generics. Go has builtin support for a few specific generic functions. Things 
like len(), copy(), append(), range, new(), make() etc. But notice how range is 
rather strange. Proper generics support from the beginning might have produced 
a different kind of range. Ideally user defined types should be as first class 
as builtin types (including support for generics). Go falls short in this 
regard (IMHO).

-- 
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/375F0FFD-F93C-4A98-B035-E60A0E41F9D5%40iitbombay.org.

Re: [go-nuts] multicasting with encoding/gob

2020-12-23 Thread Bakul Shah

I looked at your top level README.md to understand what you are doing.
Do these players join at the same time or different times? If different times, 
that can explain corruption with MultiWriter.

One suggestion is to use "bufio" to create a writer for the gob encoder out of 
a []byte buffer. Then after each encoding, grab the buffer and send it out to 
each receiver on a separate connection. This costs the encoding overhead just 
once regardless of receivers. You may have to play with this a bit to make sure 
the receiver side decoder works seamlessly even when you send N such byte 
strings. [I haven't looked at how gob is implemented so don't know if this is 
possible]

I'd avoid UDP unless your app can tolerate some loss. If you need reliable 
delivery, you may as well use TCP. Also, don't expect UDP broadcast to work 
across the Internet!

Probably a good idea to use JSON as others have suggested, as you can then 
interoperate with programs written in other languages. [In general external 
interfaces should be language neutral]

> On Dec 23, 2020, at 1:45 PM, meera  wrote:
> 
> I am trying to create a package for game servers using gob. The current 
> approach is an application level multicasting over TCP, having a gob encoder 
> and decoder for each player connection, and set up a goroutine to receive and 
> another to dispatch for each one. The code for the dispatcher is here. But 
> summarized, it simply receives data from a channel and encodes it.
> 
> The problem is that if i want to transmit a single piece of data to all 
> players, this piece of data is encoded again and again for each connection, 
> doing duplicate work. With less than 100 players this is not a problem, but 
> with 300+ my machine is at almost 100% usage and the profiler shows that most 
> of it is spent on encoding. Here's the issue on github.
> 
> I tryied using a io.MultiWriter but gob complains of duplicate type received, 
> and if i try to write the raw bytes from the gob.Encoder i get corrupted 
> data. An option is using UDP Broadcasting but since gob expects a stream, i'm 
> affraid i will run into unexpected behavior when packets start to be lost and 
> fragmented.
> 
> Does gob expect a single encoder and decoder to own the stream? Not allowing 
> two encoders on the server for one decoder on the client?
> 
> -- 
> 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/0562184e-bbcc-44c9-adbf-37e8d5411c7cn%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/E9ADC6CE-1376-4D89-9030-F56F2CE9DC36%40iitbombay.org.

Re: [go-nuts] mount remote storage without FUSE

2020-11-26 Thread Bakul Shah

This may help: https://github.com/zargony/fuse-rs

The kernel driver is provided by the FUSE project, the userspace implementation 
needs to be provided by the developer. fuse-rs provides a replacement for the 
libfuse userspace library between these two. This way, a developer can fully 
take advantage of the Rust type interface and runtime features when building a 
FUSE filesystem in Rust.

Go implementation should be possible.

> On Nov 25, 2020, at 12:38 AM, ChrisLu  wrote:
> 
> Hi, Gophers (who are also good in C),
> 
> Currently I am using FUSE to mount and write to remote storage. 
> The library I am using is Basil Fuse. The performance is good as far as FUSE 
> can go.
> 
> User -> file.write() -> Linux Kernel -> Virtual File System -> libfuse -> 
> FUSE -> DFS Client(in Go) -> Remote Storage
> 
> However, I am researching how to write directly through linux virtual file 
> system, skipping FUSE layer. Seems all similar libraries are in C. Is this 
> even possible in Go?
> 
> User -> file.write() -> Linux Kernel -> Virtual File System -> DFS Client(in 
> Go) -> Remote Storage
> 
> Thanks! 
> 
> Chris
> https://github.com/chrislusf/seaweedfs
> 
> 
> -- 
> 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/6f4c54fb-d5a5-4a1f-9840-0fbab596f785n%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/5836049F-1EEC-4B43-85AC-21B32F78DC0D%40iitbombay.org.

Re: [go-nuts] zombie parent scenario with golang

2020-09-11 Thread Bakul Shah

1. Looks like*something* in ps reports process/thread state incorrectly. It 
should not report  until all the pthreads have exited and the parent 
has not picked up the status. The runtime will call exit() when the last thread 
terminates (exit() in turn will call the _exit syscall).

2. If any thread calls _exit(), the system will clean up everything. It doesn't 
matter how many threads may  be active. You can see this for yourself if you 
replaced pthread_exit() in main() with _exit(0).

3. stacktrace within the kernel mode is irrelevant. You are merely confusing 
yourself.

4. Go runtime doesn't use pthread so not sure testing pthread based C program 
is relevant. Exiting from func main() will kill all goroutines. Copy 
https://play.golang.org/p/zRfhvfYt_oE locally and see for yourself.

5. Looking at your original message, it *seems* like a parent is not picking up 
the child's status. But I can't be sure.

I suspect you are on a wild goose chase. Possibly confused by ps. You may wish 
to backtrack to whatever you were looking at before this  came up. Or 
try explaining what is going on with your go program and what you expect it 
should do, without stacktrace or C programs etc.

I wouldn't switch to a newer kernel if I were you. When debugging you should 
keep everything else fixed or else you may end up chasing something different 
or the symptom may change or disappear.

> On Sep 10, 2020, at 10:08 PM, Uday Kiran Jonnala  wrote:
> 
> Thanks Kurtis for the reply. I understand defunct process mechanism. 
> 
> As I mentioned in the initial mail, [Correct me if I am wrong here], In a 
> process if there is main thread and a detached thread created by main thread, 
> when the main thread exits the process is kept in defunct state, since the 
> created thread is still
> executing, I was thinking if we have such scenario in go runtime. That could 
> be the reason I see this thread is waiting on futex and holding the file 
> handles and causing the go process (kernel) not to send SIGCHLD to parent 
> process.
> 
> For example below case
> 
> #include 
> #include 
> #include 
> #include 
> 
> void *thread_function(void *args)
> {
> printf("The is new thread! Sleep 20 seconds...\n");
> sleep(100);
> printf("Exit from thread\n");
> pthread_exit(0);
> }
> 
> int main(int argc, char **argv)
> {
>  pthread_t thrd;
>  pthread_attr_t attr;
>  int res = 0;
>  res = pthread_attr_init();
>  res = pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
>  res = pthread_create(, , thread_function, NULL);
>  res = pthread_attr_destroy();
>  printf("Main thread. Sleep 5 seconds\n");
>  sleep(5);
>  printf("Exit from main process\n");
>  pthread_exit(0);
> }
> 
> ujonnala@ ~/mycode/go () $ ps -T
>PID   SPID TTY  TIME CMD
>  43635  43635 pts/29   00:00:00 a.out 
>  43635  43638 pts/29   00:00:00 a.out
> 
> Due to the detached thread still executing the process left in defunt state. 
> 
> Thanks for checking on this, I will see if we can reproduce my situation on a 
> newer kernel.
> 
> Thanks & Regards,
> Uday Kiran
> 
> On Thursday, September 10, 2020 at 9:49:06 PM UTC-7 Kurtis Rader wrote:
> On Thu, Sep 10, 2020 at 9:25 PM Uday Kiran Jonnala  > wrote:
> Thanks for the reply. We are fixing the issue. But the point I wanted to 
> bring it up here is the issue of a thread causing the go process to be in 
> defunct state.
> 
> Any thread can cause the go process to enter the "defunct" state. For 
> example, by calling os.Exit(), or panic(), or causing a signal to be 
> delivered that terminates the process (e.g., SIGSEGV).
>  
> My kernel version is 
> Linux version 4.14.175-1.nutanix.20200709.el7.x86_64 (dev@ca4b0551898c) (gcc 
> version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)) #1 SMP Fri Jul 10 02:17:54 
> UTC 2020
> 
> Is that the output of `uname -a`? It seems to suggest you're using CentOS 
> provided by the https://www.nutanix.com/go/linux-on-ahv 
>  cloud environment. So we've 
> established you are using Linux with kernel version 4.14. A kernel that is 
> now three years old. I don't have anything like it installed on any of my 
> virtual machines so I can't explore how it handles defunct processes. But my 
> prior point stands: A "defunct" process is one that has been terminated but 
> whose parent process has not reaped its exit status. Either that parent 
> process has a bug (the most likely explanation) or your OS has a bug.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/ad4843e1-f7d1-43ae-8091-579bc61527fdn%40googlegroups.com
>  
>

Re: [go-nuts] List inside struct

2020-08-29 Thread Bakul Shah

Unless there is a very strong reason to use a doubly linked list, you should 
just use a slice:

type Persons struct { name string; Names []string }

I redid your program using the above here: 
https://play.golang.org/p/x5I1wYiCNGA 

Sounds like you are coming from some object oriented language background.
Suggest reading "Effective Go": https://golang.org/doc/effective_go.html 


> On Aug 29, 2020, at 9:35 AM, Shyaka  wrote:
> 
> Hello, I need help, I have a struct Person wiith list inside, I add 5 string 
> on list at the end I found that the list is nil, I don't know whre is the 
> error, any help is appreciated.
> 
> package main
> 
> import (
> "container/list"
> "fmt"
> )
> 
> type Persons struct {
> name  string
> Names list.List
> }
> 
> func main() {
> 
> p := {
> name:  "",
> Names: *list.New(),
> }
> p.setName("John Peter")
> p.add("one")
> p.add("two")
> p.add("three")
> p.add("four")
> p.add("five")
> p.display()
> 
> }
> 
> func (p *Persons) setName(name string) {
> p.name = name
> }
> func (p *Persons) add(name string) {
> p.Names.PushBack(name)
> }
> func (p *Persons) display() {
> fmt.Println(p.name)
> for e := p.Names.Front(); e != nil; e = e.Next() {
> fmt.Println(e.Value)
> }
> }
> 
> -- 
> 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/e8975da6-9af2-4660-8dbb-1a7e7e9b67cfn%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/886C6A94-BC0A-4968-8A2A-74FD09215533%40iitbombay.org.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread Bakul Shah

On Aug 21, 2020, at 2:07 PM, roger peppe  wrote:
> 
> Here's one interesting implication of this: it allows us to do type 
> conversions that were not previously possible.
> 
> For example, if we have "type I int", we can use a type switch to convert 
> some type []I to type []int:
> https://go2goplay.golang.org/p/-860Zlz7-cn
> 
> func F[type T intlike](ts []T) []int {
>switch T {
>case int:
>return ts
>}
>return nil
> }

IMHO this should work. This makes sense to me because I think
of generics as merely constrained compile time macros :-) The
switch can removed at compile time by the compiler. [Note that
in this regard "intlike" is *different* from sum types, which are
a runtime concept that Go doesn't have (except for interface{}).]

-- 
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/74732864-340B-4F23-A578-7E6C65DE256D%40iitbombay.org.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

2020-08-21 Thread Bakul Shah

On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor  wrote:
> 
> After many discussions and reading many comments, we plan to move
> forward with some changes and clarifications to the generics design
> draft.
> 
> 1.
> 
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary parameter list.  To avoid the ambiguity with
> array declarations, we will require that all type parameters provide a
> constraint.  This has the advantage of giving type parameter lists the
> exact same syntax as ordinary parameter lists (other than using square
> brackets).  To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.

Great!


> 2.
> 
> We’re going to simplify the rule for type list satisfaction.  The type
> argument will satisfy the constraint if the type argument is identical
> to any type in the type list, or if the underlying type of the type
> argument is identical to any type in the type list.  What we are
> removing here is any use of the underlying types of the types in the
> type list.  This tweaked rule means that the type list can decide
> whether to accept an exact defined type, other than a predeclared
> type, or whether to accept any type with a matching underlying type.
> 
> This is a subtle change that we don’t expect to affect any existing
> experimental code.
> 
> We think that this definition might work if we permit interface types
> with type lists to be used outside of type constraints.  Such
> interfaces would effectively act like sum types. That is not part of
> this design draft, but it’s an obvious thing to consider for the
> future.
> 
> Note that a type list can mention type parameters (that is, other type
> parameters in the same type parameter list).  These will be checked by
> first replacing the type parameter(s) with the corresponding type
> argument(s), and then using the rule described above.

Still uncomfortable with this. Will try to expand on this in a separate
email.

> 3.
> 
> We’re going to clarify that when considering the operations permitted
> for a value whose type is a type parameter, we will ignore the methods
> of any types in the type list.  The general rule is that the generic
> function can use any operation permitted by every type in the type
> list.  However, this will only apply to operators and predeclared
> functions (such as "len" and "cap").  It won’t apply to methods, for
> the case where the type list includes a list of types that all define
> some method.  Any methods must be listed separately in the interface
> type, not inherited from the type list.
> 
> This rule seems generally clear, and avoids some complex reasoning
> involving type lists that include structs with embedded type
> parameters.

You seem to be saying a generic function can use operator X only if
if *every* type in the type list implements it. Thus if I have

type foo interface { int; someSLice }

I can't use + and I can't use len(), right?

-- 
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/10264F88-82EB-4E01-AF28-E2057C08571E%40iitbombay.org.

Re: [go-nuts] How to find repeated string?

2020-08-19 Thread Bakul Shah

On Aug 19, 2020, at 1:07 AM, 洪嘉鴻  wrote:
> 
> Hello everyone:
> I use golang with Win10. The version of golang which I'm using is go1.15.
> I want to find out the repeated string.
> For example, given a string which is "1134534534534534".
> I want the output string to be "345"
> I've tried to 
> Could anyone help me to solve this problem?

Your problem specification is ambiguous. For example, if you may be able
represent your input string as

...S^N... or 
...T^M... or 
...U...V..U..V..V.. where there are U occurs L times and V occurs K times.
Here S, T, U and V are substrings

Then any of the following possible answers may make sense:
1. S if len(S) > len(any T)
2. T if M > N (T occurs more frequently than any S)
3. U if len(U) > len(any V)
4. V if K > L (V occurs more frequently than any U)

Based on your example it appears you want 2. or 4. but can't be sure.
Specify the problem clearly & completely and the solution will usually
suggest itself!

-- 
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/62DA1B47-04CD-4B21-8F32-A0A907983757%40iitbombay.org.

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

2020-08-13 Thread Bakul Shah

On Aug 13, 2020, at 3:29 PM, Michael Jones  wrote:
> 
> The all-or-none aspect would be sidestepped if it were allowed to define 
> "partial generics":
> 
> func A (T1, T2) (...){}
> 
> func B(T)(...){ A(T,int)(...){...} }
> 
> Allowing B to exist just means running the whole generic thing iteratively 
> until no resolution is changed. If the fixed point still has generic types 
> then the compilation is a failure, otherwise, a success.

Do you mean something like this? https://go2goplay.golang.org/p/4I4y-dLC-Yp

> 
> Seems useful to me. A generic balanced tree infrastructure could be 
> "meta-instantiated" as a LLRB instance that still allows generic leaf types.

-- 
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/797021AB-A5A4-490B-A07B-0BF4700FC429%40iitbombay.org.

Re: [go-nuts] [generics] Feedback on optional type keyword experiment

2020-07-25 Thread Bakul Shah

I like it!

BTW, I don't understand the meaning of this comment in the commit log:

> >> Experiment: Make "type" keyword optional in generic type declarations when 
> >> it is clear that we can't have an array type declaration.

It is talking about defining generic arrays, where one parameter may be the 
number of dimensions?
Probably not but IMHO such an exercise should be carried out before settling on 
a generic design.


> On Jul 25, 2020, at 1:36 PM, 'Carla Pfaff' via golang-nuts 
>  wrote:
> 
> I know it's common to have no constraints, but "[Elem any]" is even one 
> character shorter than "[type Elem]". I rewrote the function signatures from 
> slices.go2 in this way, and it doesn't feel painful. This already works on 
> the go2go playground: https://go2goplay.golang.org/p/IQV5LTAIuDr
> 
> On Saturday, 25 July 2020 at 22:22:24 UTC+2 Ian Lance Taylor wrote:
> On Sat, Jul 25, 2020 at 11:47 AM 'Carla Pfaff' via golang-nuts 
>  > wrote: 
> > 
> > To expand on my post: 
> > It would be very consistent with the structure of regular parameter lists. 
> > Just like every parameter in a regular parameter list must have a type 
> > (with the exception of multiple consecutive parameters having the same 
> > type), every type parameter in a type parameter list must have a 
> > constraint. 
> 
> That is certainly true. 
> 
> But it is also true, based on experiments writing generic code, that 
> the majority of type parameters have no constraints. That is 
> particularly true for type parameters of generic types. So while it 
> would be possible to require people to always explicitly write a 
> constraint, it seems painful to force people to always write something 
> that is almost never needed. 
> 
> Note that in this way constraints on type parameters are different 
> from types of regular parameters. It makes no sense to speak of a 
> regular parameter with no type. It's entirely reasonable, even 
> common, to speak of a type parameter with no constraint. 
> 
> Ian 
> 
> 
> > On Saturday, 25 July 2020 at 20:26:37 UTC+2 Carla Pfaff wrote: 
> >> 
> >> I just discovered the experiment to make the "type" keyword optional in 
> >> certain cases on the dev.go2go branch. The commit message says: 
> >> 
> >> --- 
> >> Experiment: Make "type" keyword optional in generic type declarations when 
> >> it is clear that we can't have an array type declaration. This is the case 
> >> when we have one the following: 
> >> 
> >> - more than one type parameter 
> >> - a type parameter with a constraint 
> >> - a trailing comma in the type parameter list 
> >> -- 
> >> 
> >> If the "type" keyword is not necessary if a constraint is present, then 
> >> why not make a constraint mandatory and get rid of the "type" keyword in 
> >> type parameter lists altogether? 
> >> 
> >> Before: 
> >> 
> >> func Filter[type Elem](...) 
> >> func Map[Elem1, Elem2](...) 
> >> func Max[Elem constraints.Ordered](...) 
> >> 
> >> After: 
> >> 
> >> func Filter[Elem interface{}](...) 
> >> func Map[Elem1, Elem2 interface{}](...) 
> >> func Max[Elem constraints.Ordered](...) 
> >> 
> >> "interface{}" may be a little bulky, especially it since it is usually 
> >> used for the simple cases. But if there was a short type alias for 
> >> "interface{}" like "any" it can look good: 
> >> 
> >> type any = interface{} 
> >> 
> >> func Filter[Elem any](...) 
> >> func Map[Elem1, Elem2 any](...) 
> >> func Max[Elem constraints.Ordered](...) 
> >> 
> > -- 
> > 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/d7a9fe08-73bb-487b-ba2a-6766560f3b03n%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/751b84b1-c3b6-4b81-8b9d-845805dc1ae5n%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/1FEE7F98-958D-4481-B76F-F84B3D9B9211%40iitbombay.org.

Re: [go-nuts] Generics and parentheses

2020-07-15 Thread Bakul Shah



> On Jul 15, 2020, at 1:49 PM, Ian Lance Taylor  wrote:
> 
> On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah  wrote:
>> 
>> I don't much like square brackets or angle brackets or guillemets. But here 
>> is a different way
>> of reducing the need for parentheses at least for the common case:
>> 
>> A proposal for fewer irritating parentheses!
>> 
>> One thing to note is that generic functions & types are *different* from
>> existing things like const, func, type, var. As such they should have their
>> own declaration marker. For example
>> 
>> gen T   type pair struct { a, b T } // contrast with type pair(type T) ...
>> gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ...
>> gen T   func Print(s []T) {...} // print a slice of T
>> 
>> These function/type/method generics are used by *prepending* the type:
>> 
>> var x int pair // a pair of ints
>> var y (int, int pair) W // here we have to use parentheses
>> int Print([]int{1,2,3}) // print a slice of ints
>> qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
>> ww := (int, int) W pair{{1,2},{3,4}}
>> 
>> This use may seem weird if you are used to C/C++. I find it more readable
>> than having to deal with extra parentheses. "int pair" clearly says a
>> pair of ints and so on. What is more, if in future types are allowed to be
>> *inferred* for generic function calls, you can simply drop the type prefix.
>> 
>> If there is still a parsing ambiguity, I'd suggest adding a - as in int-pair.
>> 
>> Additional type syntax rule:
>> 
>> type: ... | type generic-type| (type-list) generic-type
>> 
>> or
>> 
>> type: ... | type "-" generic-type | (type-list) "-" generic-type
>> 
>> FWIW I thought of this four weeks ago (June 16).
> 
> 
> Thanks for the note.  It's an interesting idea, but I'm not quite sure
> it works to have prefix types with no real delimiters.  It may work to
> write "int pair pair" but does it work to write "func() int pair
> pair"?  That is the type of a pair of functions where each function
> returns the type "int pair".  If we have to start carefully deciding
> where we need to add parentheses then I'm not sure we've gained very
> much by switching to this kind of syntax.

The syntax rule I envisioned was this:
type: ... | type generic-type | ...

To me, using full parenthesization, this would be
func() int pair pair" == "((func() int) pair)pair --(1)
What you seem to want is
(func() (int pair)) pair --(2)

Contrast that with
pair[pair[func() int]] --(1)
and
pair[func()pair[int]] --(2)

As I see it, the alternate syntax is no worse for extreme cases but much better 
for the common case.

The second issue is the usage for generic functions. Contrast

(float64, int)PowN(1.2, 3)
with
PowN[float64, int](1.2, 3)
or currently
PowN(float64, int)(1.2, 3)

I find the alternate syntax easier because conceptually the concrete types  
used to select a specific concrete function is a different activity than 
passing arguments to a function at runtime so IMHO they should be visually 
different.  It is almost like  C style cast. Think of it as casting a generic 
function (or type) to a concrete function or type!


-- 
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/65AF00C2-1CAE-4876-84A8-8BADD4A740CE%40iitbombay.org.

Re: [go-nuts] Generics and parentheses

2020-07-15 Thread Bakul Shah

As I wrote, parentheses are not needed  for the common case of single type
parameter. If you have more than one, you need parentheses but note that this
is a *prefix* and any parsing ambiguities can removed by using  a - if needed.
For your example it will be something like

(float64,int)PowN(1.2, 3)

It’s just a syntax change. There is zero semantic difference from the current
proposal. I just tried to get idea across - I can work out a complete set of
syntax rule changes if there is sufficient interest but the gen rule will be
something like

gen-type-decl: gen-prefix type-decl;
gen-func-decl: gen-prefix func-decl;
gen-prefix: “gen” typeX-list
typeX-list: typeX | typeX-list “,” typeX ;
typeX: NAME [constraint] ;

> On Jul 15, 2020, at 12:01 AM, 'Dan Kortschak' via golang-nuts 
>  wrote:
> 
> How do these deal with non-type determined uses. Say you have (by any
> spelling)
> 
> gen F,I func PowN(a F, b I) F {...}
> 
> How do you specify the type of F or I when say you have untyped
> constants. This still requires parens or other markings to indicate the
> actual types of F and I. It seems many of the comments here complaining
> about brackets and such are ignoring this aspect of the current
> proposal.

-- 
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/A7BB89C9-ADDC-4C25-B8DE-EC0F358B5D33%40iitbombay.org.

Re: [go-nuts] Generics and parentheses

2020-07-15 Thread Bakul Shah

I don't much like square brackets or angle brackets or guillemets. But here is 
a different way
of reducing the need for parentheses at least for the common case:

A proposal for fewer irritating parentheses!

One thing to note is that generic functions & types are *different* from
existing things like const, func, type, var. As such they should have their
own declaration marker. For example

gen T   type pair struct { a, b T } // contrast with type pair(type 
T) ...
gen T,U type W struct { a T; b U }  // contrast with type W(type T, 
U) ...
gen T   func Print(s []T) {...} // print a slice of T

These function/type/method generics are used by *prepending* the type:

var x int pair  // a pair of ints
var y (int, int pair) W // here we have to use parentheses
int Print([]int{1,2,3}) // print a slice of ints
qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
ww := (int, int) W pair{{1,2},{3,4}}

This use may seem weird if you are used to C/C++. I find it more readable
than having to deal with extra parentheses. "int pair" clearly says a
pair of ints and so on. What is more, if in future types are allowed to be
*inferred* for generic function calls, you can simply drop the type prefix.

If there is still a parsing ambiguity, I'd suggest adding a - as in int-pair.

Additional type syntax rule:

type: ... | type generic-type| (type-list) generic-type

or

type: ... | type "-" generic-type | (type-list) "-" generic-type

FWIW I thought of this four weeks ago (June 16).

> On Jul 14, 2020, at 3:29 PM, 'gri' via golang-nuts 
>  wrote:
> 
> Correction: The last paragraph in the post below should have said: "In Go, 
> type information is not available at parse time". (Of course, type 
> information is available at compile time.)
> 
> On Tuesday, July 14, 2020 at 2:56:01 PM UTC-7 gri wrote:
> We have received a variety of feedback on the generics draft design 
> 
>  (blog ). Thanks to everyone who 
> took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
> 
> Not unexpectedly, many people raised concerns about the syntax, specifically 
> the choice of parentheses for type parameter declarations and generic type 
> and function instantiations.
> 
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square brackets 
> [ and ], curly braces { and }, and angle brackets < and >. Go uses curly 
> braces to delineate code blocks, composite literals, and some composite 
> types, making it virtually impossible to use them for generics without severe 
> syntactic problems. Angle brackets require unbounded parser look-ahead or 
> type information in certain situations (see the end of this e-mail for an 
> example). This leaves us with parentheses and square brackets. Unadorned 
> square brackets cause ambiguities in type declarations of arrays and slices, 
> and to a lesser extent when parsing index expressions. Thus, early on in the 
> design, we settled on parentheses as they seemed to provide a Go-like feel 
> and appeared to have the fewest problems.
> 
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses in 
> order to focus on the bigger design issues.
> 
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
> 
>   type A [N]E
> 
> cannot be distinguished from the generic type declaration
> 
>   type A[N] E
> 
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
> 
>   type A[type N] E
> 
> (When we originally dismissed square brackets, the type keyword was not yet 
> on the table.)
> 
> Furthermore, the ambiguities that arise with parentheses appear not to arise 
> with square brackets. Here are some examples where extra parentheses are not 
> needed with square brackets:
> 
>   using () using []
>   func f((T(int))  func f(T[int])
>   struct{ (T(int)) }   struct{ T[int] }
>   interface{ (T(int)) }interface{ T[int] }
>   [](T(int)){} []T[int]{}
> 
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation such 
> that it accepts either parentheses or square brackets (only one or the other) 
> in a generic Go package. Those

Re: [go-nuts] var fn myHandler = func(){ fn }

2020-07-12 Thread Bakul Shah

On Jul 12, 2020, at 1:43 PM, Axel Wagner  wrote:
> 
> 
> 
> On Sun, Jul 12, 2020 at 9:33 PM Bakul Shah  wrote:
> On Jul 12, 2020, at 11:11 AM, Gert  wrote:
> > 
> > https://play.golang.org/p/6xMgjr1IyFD
> > 
> > var fn myHandler
> > fn = func(w http.ResponseWriter, r *http.Request) {
> >   fn.GET(w, r)
> > }
> > 
> > Just wondering if it's possible somehow to write this in one line like so
> > 
> > var fn myHandler = func(w http.ResponseWriter, r *http.Request) {
> >   fn.GET(w, r)
> > }
> 
> The issue is that fn's type can't be completely determined until
> the RHS func is fully analyzed but for that to work fn must be
> known!
> 
> Why? ISTM the type is mentioned twice - once as "myHandler" on the LHS and 
> once in the signature on the RHS. And there isn't even a way to write down a 
> function literal without mentioning the full type. On the surface, this seems 
> like a relatively straightforward scoping issue, introduced by the fact that 
> the scope of a variable declaration starts at the end of it's VarSpec, not 
> the "=". Interestingly though, the initialization rules prevent this from 
> working at the package-level, where this scoping problem doesn't exist: 
> https://play.golang.org/p/IPMxtYETGsg

You're right.

> 
> Also note that the first definition won't do what you may be thinking
> it does. The`fn.GET` call will be to the existing value of fn, not
> the result of the assignment.
> 
> No, it won't. The function-literal closes over `fn`, so it will use whatever 
> is assigned at call-time.
> https://play.golang.org/p/VCvCt8J8Zcw
> I use this pattern all the time to define a recursive function without 
> polluting the package-scope.

Right again. What matters is the value of fn when the function is called,
not when it is defined. Clearly I wasn't thinking clearly.

Thanks for setting me straight. And apologies to Gert.

-- 
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/9D3EE282-2C7A-42DA-8282-CBFFF9C3935A%40iitbombay.org.

Re: [go-nuts] var fn myHandler = func(){ fn }

2020-07-12 Thread Bakul Shah

On Jul 12, 2020, at 11:11 AM, Gert  wrote:
> 
> https://play.golang.org/p/6xMgjr1IyFD
> 
> var fn myHandler
> fn = func(w http.ResponseWriter, r *http.Request) {
>   fn.GET(w, r)
> }
> 
> Just wondering if it's possible somehow to write this in one line like so
> 
> var fn myHandler = func(w http.ResponseWriter, r *http.Request) {
>   fn.GET(w, r)
> }

The issue is that fn's type can't be completely determined until
the RHS func is fully analyzed but for that to work fn must be
known! This is not a problem when a "const" function references
itself as in `func foo() { ... foo() ... }`.

Also note that the first definition won't do what you may be thinking
it does. The`fn.GET` call will be to the existing value of fn, not
the result of the assignment.

-- 
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/716C7D59-9F2B-4AAD-8560-79011359A96C%40iitbombay.org.

Re: [go-nuts] filepath.Abs ignores '~'

2020-07-07 Thread Bakul Shah

You can do this:

home, _ := os.UserHomeDir() 
absPath := home + "/trunk/infra/metadata/config.cfg"

> On Jul 7, 2020, at 4:32 PM, 'Jacob Kopczynski' via golang-nuts 
>  wrote:
> 
> I tried to state a path relative to the home directory, since in the context 
> I am writing for the path from ~ to the Git repository will be consistent, 
> though the meaning of ~ may change based on user. A snippet:
> 
> const specPath = "~/trunk/infra/metadata/config.cfg"
> absPath, _ := filepath.Abs(specPath) 
> if err := readJSONPb(absPath, ); err != nil {  
> fmt.Printf("specPath is %s, or as absolute %s\n", specPath, absPath)
> return nil, errors.Annotate(err, "extracting tests from spec").Err()
> }
> However, this produces this output:
> specPath is ~/trunk/infra/metadata/config.cfg, or as absolute 
> /home/jkop/trunk/infra/~/trunk/infra/metadata/config.cfg
> extracting tests from spec: read JSON pb: open 
> /home/jkop/trunk/infra/~/trunk/infra/metadata/config.cfg: no such file or 
> directory
> 
> This is a) surprising, since I would expect a platform-sensitive absolute 
> path function to deal with platform-global shortcuts like ~, and b) 
> completely undocumented. The docs say that "Abs returns an absolute 
> representation of path. If the path is not absolute it will be joined with 
> the current working directory to turn it into an absolute path." It doesn't 
> say "If the path is not rooted", but "not absolute". This is not an absolute 
> representation but it does specify an absolute path unambiguously.
> 
> What's the process for submitting a change to a core library like this one? 
> Ideally, to the code, but I'd settle for making the documentation clearer.
> 
> -- 
> 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/ee99cbb9-583f-487f-9e57-e0072d7a859an%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/E7D2DCBD-19F8-4497-AA6E-45E014130613%40iitbombay.org.

Re: [go-nuts] draft design for // +build replacement

2020-07-01 Thread Bakul Shah

My suggestion was a variation on rsc's #2. Still a simple rule that is easy
for people to remember and doesn't require asking the go command.
Prefer a simple rule compared to any intermediation by a program.

> On Jul 1, 2020, at 11:54 AM, jimmy frasche  wrote:
> 
> Running find -name "*_*.go" | xargs grep " +build" on goroot shows a
> lot of files with redundant build tags or additional constraints not
> present in the file name so they don't seem like much of a single
> point of truth.
> 
> I'd be fine with removing file names sometimes implying build tags.
> Add build tags from the filename to the go:build line and after go1.X
> stop getting build tags from the file name.
> 
> There would still be special cases like _test and cgo but there would
> be fewer special cases. Option 3 looks like a solid plan to handle the
> hypothetical _fuzz even if otherwise things converge on go:build.
> 
> On Wed, Jul 1, 2020 at 11:20 AM Bakul Shah  wrote:
>> 
>> 4. Use two underscores for constraints. At least new constraints.
>> 
>> Aside: Are you plantin' an idea about Plan10?
>> 
>> On Jul 1, 2020, at 11:06 AM, Russ Cox  wrote:
>> 
>> For what it's worth, I am (unsurprisingly) a big fan of the filename-based 
>> constraints. It's a lightweight convention that has served us incredibly 
>> well. I really like being able to see in a directory listing which files go 
>> with what. It would be unfortunate if we had to put the redundant info 
>> inside files and then hope that the info inside matched the file names 
>> and/or introduce consistency checks. A single point of truth always seems 
>> better to me than verified redundancy.
>> 
>> But I certainly hear your point about what happens when a new OS comes along 
>> (plan10, say) and none of the old Go releases know that foo_plan10.go should 
>> be ignored except when GOOS=plan10. If we were going to seriously consider 
>> fixing the filename-based constraint ambiguity (probably not today), there 
>> are at least three possible paths forward.
>> 
>> 1. Remove the ambiguity by making _foo in a filename never a constraint, as 
>> you've proposed. For me, this throws the baby out with the bathwater.
>> 
>> 2. Remove the ambiguity by making _foo in a filename always a constraint. If 
>> a toolchain doesn't know what foo means, then the constraint is clearly not 
>> satisfied. I think this would be too painful to deploy. I ran a scan last 
>> night and there are just far too many files using underscores for 
>> non-constraints today.
>> 
>> 3. Two steps:
>> 3a. Make the go command apply a list based on the go version in go.mod, so 
>> that we can say "as of Go 1.16, plan10 is a recognized GOOS". Then when 
>> building old code, any existing foo_plan10.go file doesn't get reinterpreted.
>> 3b. Remove uncertainty in tools by making them ask the go command (perhaps 
>> using x/tools/go/packages), which always knows.
>> 
>> I think I would lean more toward 3 than 1 or 2. As someone noted, we're 
>> certainly not going to start requiring //go:build test in every *_test.go 
>> file - that convention won't go away. But then what happens when the next 
>> thing comes along? What if for fuzzing turns out to be very helpful to have 
>> a foo_fuzz.go convention? (Probably not, but what about the next thing?) If 
>> we get all the tools asking the go command, then that kind of change is easy 
>> to deploy. (Similarly, files with import "C" only apply when the cgo tag is 
>> set. I don't think it makes sense for tools to be hard-coding that rule, nor 
>> would it make sense at this point to require an explicit //go:build cgo. If 
>> tools ask the go command instead of trying to rederive these kinds of things 
>> themselves, it's no problem at all.)
>> 
>> I would be very interested to hear about which tools can't ask the go 
>> command for this info, and why, and what we can do to address that.
>> 
>> Best,
>> Russ
>> 
>> 
>> --
>> 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/CAA8EjDQbwP6zsmr%2BYHw4hQbVv8c%2BkUvMAMowMb3o_%2B%3DnUu5Z2Q%40mail.gmail.com.
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this grou

Re: [go-nuts] draft design for // +build replacement

2020-07-01 Thread Bakul Shah

4. Use two underscores for constraints. At least new constraints.

Aside: Are you plantin' an idea about Plan10?

> On Jul 1, 2020, at 11:06 AM, Russ Cox  wrote:
> 
> For what it's worth, I am (unsurprisingly) a big fan of the filename-based 
> constraints. It's a lightweight convention that has served us incredibly 
> well. I really like being able to see in a directory listing which files go 
> with what. It would be unfortunate if we had to put the redundant info inside 
> files and then hope that the info inside matched the file names and/or 
> introduce consistency checks. A single point of truth always seems better to 
> me than verified redundancy.
> 
> But I certainly hear your point about what happens when a new OS comes along 
> (plan10, say) and none of the old Go releases know that foo_plan10.go should 
> be ignored except when GOOS=plan10. If we were going to seriously consider 
> fixing the filename-based constraint ambiguity (probably not today), there 
> are at least three possible paths forward. 
> 
> 1. Remove the ambiguity by making _foo in a filename never a constraint, as 
> you've proposed. For me, this throws the baby out with the bathwater.
> 
> 2. Remove the ambiguity by making _foo in a filename always a constraint. If 
> a toolchain doesn't know what foo means, then the constraint is clearly not 
> satisfied. I think this would be too painful to deploy. I ran a scan last 
> night and there are just far too many files using underscores for 
> non-constraints today.
> 
> 3. Two steps:
> 3a. Make the go command apply a list based on the go version in go.mod, so 
> that we can say "as of Go 1.16, plan10 is a recognized GOOS". Then when 
> building old code, any existing foo_plan10.go file doesn't get reinterpreted. 
> 3b. Remove uncertainty in tools by making them ask the go command (perhaps 
> using x/tools/go/packages), which always knows.
> 
> I think I would lean more toward 3 than 1 or 2. As someone noted, we're 
> certainly not going to start requiring //go:build test in every *_test.go 
> file - that convention won't go away. But then what happens when the next 
> thing comes along? What if for fuzzing turns out to be very helpful to have a 
> foo_fuzz.go convention? (Probably not, but what about the next thing?) If we 
> get all the tools asking the go command, then that kind of change is easy to 
> deploy. (Similarly, files with import "C" only apply when the cgo tag is set. 
> I don't think it makes sense for tools to be hard-coding that rule, nor would 
> it make sense at this point to require an explicit //go:build cgo. If tools 
> ask the go command instead of trying to rederive these kinds of things 
> themselves, it's no problem at all.)
> 
> I would be very interested to hear about which tools can't ask the go command 
> for this info, and why, and what we can do to address that.
> 
> Best,
> Russ
> 
> 
> -- 
> 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/CAA8EjDQbwP6zsmr%2BYHw4hQbVv8c%2BkUvMAMowMb3o_%2B%3DnUu5Z2Q%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/443ACF21-0A34-484D-B1E3-273E6226E96C%40iitbombay.org.

Re: [go-nuts] Bitstring package?

2020-06-29 Thread Bakul Shah

Won't https://golang.org/pkg/math/bits/  do?

> On Jun 29, 2020, at 6:58 PM, hardconnect@gmail.com wrote:
> 
> I'm looking for a package that implements arbitrary length bit strings and 
> supports set all, clear all, set and reading back of arbitrary bits and 
> setting and clearing the next set or unset bit.
> 
> I've seen a couple of packages that come close. Does anyone know of a package 
> that meets all my needs?
> 
> Is there a centralized search/lookup site for GO packages?
> 
> Thanks,
> 
> Joe
> 
> -- 
> 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/4a423427-186d-43df-8316-b62963fe5e1ao%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/5EDEFBE7-8CC8-4B4D-8EDC-2C1055E40102%40iitbombay.org.

Re: [go-nuts] Weird benchmark results for seemingly identical functions

2020-06-22 Thread Bakul Shah

They are not equivalent. You want if !(pos < suffixLen && pos < previousSuffixLen) {  break } in the second case.On Jun 22, 2020, at 5:15 AM, Yonatan Ben-Nes  wrote:Hi,I'm encountering a weird issue which I fail to explain. It boils down to 2 almost identical functions which give wildly different benchmark results.The difference between the functions is that at the slow func there is a for loop like this:for pos := 0; pos < suffixLen && pos < previousSuffixLen; pos++ {}While at the fast func the loop is like this:for pos := 0; true; pos++ {     if pos < suffixLen && pos < previousSuffixLen {  break     }}* do note that the check at both versions is the same.Other than that the functions are identical but when I benchmark them I get:$ go test -bench=Weird .goos: linuxgoarch: amd64BenchmarkWeirdFast-4 280394 3602 ns/opBenchmarkWeirdSlow-4   1866   618953 ns/opIt's extra weird since getting the condition check into the loop should be the slower form, or at least that what I intuitively thought.Also, the extra time cost is divided between the loop section and an append function call which run immediately at the start of the function and is not connected in any way to the for loop. And it's extra weird as the append cost also get smaller if instead of reading the test text from a file I just declare a string variable with the same text for the benchmark (mind you that I b.ResetTimer() after doing either of those options).I attached the files to this message as they will make everything more clear and I also added comments describing what happen at the right points.I'm using Ubuntu 18.04 and go is version 1.14.2, and I also checked it on a GCP compute engine and got the same results.Any thoughts will be much appreciated as I'm totally confused here! :)

-- 
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3cf40b00-96ec-42a6-8093-7f1c27bfd93fn%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/E696BA2E-7AF0-4C55-9374-0C11EF585087%40iitbombay.org.
package main

// Cost around 300k ns/op (with the append at the start of the function its above 600k ns/op)
func slow(suffixArray []string) (lcp []int) {
	// This append command cost about 50% of the time cost of the entire function.
	// This extra cost happen only when the condition expression of the inline for loop below is set as it is.
	// If the aforementioned condition expression is replaced with true (like at fast()) than its fast as expected
	lcp = append(lcp, 0)

	previousSuffixLen := len(suffixArray[0])

	for i := 1; i < len(suffixArray); i++ {
		suffixLen := len((suffixArray)[i])

		// Here the condition expression is set and it makes the function way slower
		for pos := 0; pos < suffixLen && pos < previousSuffixLen; pos++ {
		}

		previousSuffixLen = suffixLen
	}
	return lcp
}

func fast(suffixArray []string) (lcp []int) {
	// Here the append line is always fast no matter if BenchmarkNeverCalled() is commented out or not
	lcp = append(lcp, 0)

	previousSuffixLen := len((suffixArray)[0])

	for i := 1; i < len(suffixArray); i++ {
		suffixLen := len((suffixArray)[i])

		// Here I set the condition expression to true and move the condition to be inside the for loop
		// It makes the function be way faster (both the loop speed and not making the append cost way more as well)
		for pos := 0; true; pos++ {
			if pos < suffixLen && pos < previousSuffixLen {
break
			}
		}

		previousSuffixLen = suffixLen
	}

	return lcp
}




-- 
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/E696BA2E-7AF0-4C55-9374-0C11EF585087%40iitbombay.org.
package main

import (
	"io/ioutil"
	"sort"
	"testing"
)

/*
Running the following tests without changing anything give the following results at my system:

$ go test -bench=Weird .
goos: linux
goarch: amd64
BenchmarkWeirdFast-4   	  280394	  3602 ns/op
BenchmarkWeirdSlow-4   	1866	618953 ns/op
PASS
ok  	_/home/nimrod/projects/sandbox/kattis/dvaput	2.284s
*/

func BenchmarkWeirdFast(b *testing.B) {
	suffixList := createSuffixList(b)
	b.ResetTimer()

	for i := 0; i < b.N; i++ {
		fast(suffixList)
	}
}

func BenchmarkWeirdSlow(b *testing.B) {
	suffixList := createSuffixList(b)

Re: [go-nuts] How I can translate this shell command to golang code?

2020-06-22 Thread Bakul Shah

You can avoid calling the shell by observing that you are simply passing 
"123456" as input, which you can do in a Go Program itself.
See https://golang.org/pkg/os/exec/#example_Command


> On Jun 22, 2020, at 8:54 AM, Franco Marchesini  
> wrote:
> 
> Help,
> 
> how I can translate this shell command :
> 
> echo -n 123456 | dmtxwrite -s 16x48  -o image.png
> 
> to golang
> 
>  exec.Commad()
> 
> Thanks in advance
> Franco
> 
> -- 
> 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/c6aaba94-453b-41dc-83a4-ffd4f3912494o%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/2280A84F-C277-4C61-B98B-B2D369F5F5A7%40iitbombay.org.

Re: [go-nuts] [generics] Type lists should be usable in any interface

2020-06-16 Thread Bakul Shah

On Jun 16, 2020, at 7:06 PM, Brandon Dyck  wrote:
> 
> I find it a little strange that an interface with a type list can only be 
> used as a constraint, and not as the type of a variable or parameter, despite 
> it using basically the same syntax as a normal interface. Is this difference 
> between constraints and other interfaces a property of the type system, or 
> just a limitation of the translation? I don't think it was explicit in the 
> design document. It would certainly be useful to declare variables with 
> type-list interfaces, as it would provide a much less hacky way to define sum 
> types than using an unexported interface method as in 
> https://medium.com/@haya14busa/sum-union-variant-type-in-go-and-static-check-tool-of-switch-case-handling-3bfc61618b1e.

This use is not quite the same as sum types. Basically the use of
a type list in 'ordered' *stands in* for types that have ordered
comparison operators but Go doesn't have a way to specify this.
And even this did not work for the 'comparable' as the list is
open ended. Both seem to have resulted from Go's peculiarity.

In comparison a sum type can contain any types. These types need
not have anything in common. As long as an operation is qualified
with a type assertion this works.

Seems to me that perhaps 'ordered' should also be *predeclared*.
What happens if/when a big int type is added in future? Or
decimal or big floats. "The Expression Problem" comes to mind :-)

It would be nice if it was possible to extend operators for user
defined types (but I suspect people will object!). If syntax for
such existed, both 'ordered' and 'comparable' could be defined
cleanly.

I don't really see very many uses of an interface containing a
list of types.

Finally how would generics defined using 'ordered' deal with NaNs?
NaNs are unordered!

-- 
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/C4CCD5F9-AFD3-462B-B1BC-C127F9EB1884%40iitbombay.org.

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

2020-03-05 Thread Bakul Shah

On Mar 5, 2020, at 12:05 AM, roger peppe  wrote:
> 
> Having said all that, I believe there is a valid point to be made
> with regard to testing concurrent Go programs that have long-lived
> behaviour over time. It can be hard to test such programs, and I've
> not yet seen an approach that doesn't feel clunky and/or somewhat
> error-prone.

Dijkstra wrote "Testing reveals the presence, not the absence of bugs".
This is particularly true of concurrent programs! How do you ensure there
are no deadlocks? There may be too many states to test. And debugging is
even harder. How do recreate conditions for a deadlock when you don't
really know what may be the cause?

In contrast formal specification languages/tools such as TLA+/Coq/SPIN
seem to have made better headway. It would be good if specification
support can be integrated into Go. Or may be, have a separate language
analogous to the Bluespec language that can be compiled to Verilog.

-- 
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/58D60EAB-E90C-4F53-90D0-07751A232923%40bitblocks.com.

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

2020-03-03 Thread Bakul Shah

On Mar 1, 2020, at 12:43 PM, Ian Lance Taylor  wrote:
> 
> On Sun, Mar 1, 2020 at 8:21 AM Warren Stephens
>  wrote:
>> 
>> // I don't want to get into the specific syntax of the test code directly,
>> // but a test would start execution here, supplying "lines" and "thing2"
>> //
>>mystep2 with: lines, thing2  // <-- hide all local variables from 
>> above except for lines and thing2
>> 
>>mymap := make(map[string]int)
>>   for _, line := range lines {
>>   if strings.Contains(line, thing2) {
>>   count := strings.Count(line, thing2)
>>   mymap[line] = count
>>}
>>   }
>> 
>> // and the test would end here -- because the next line is another "with" 
>> (or return) statement
>> // it would be able to do Asserts and such on the variables within the scope 
>> of this code segment
>> 
>> Ian,
>> 
>> An alternative approach would be to have:
>> 
>>   mystep2 with: lines, thing2 => mymap
>> 
>> to specify all of the intermediate variables of interest for the test.
>> 
>> These testable code chunks, delimited by with statements, act like hidden 
>> funcs.  The actual call could be something like test_doSomeStuff@mystep2
> 
> To me this all seems very unlike anything else in the Go language.
> There is nothing syntactically similar to this anywhere else.  I think
> it is extremely unlikely that Go would adopt this idea.

What Warren wants seems something like "Hoare Logic", where you have a
notation such as

P{C}R

where P & R are assertions and C is a block of code. If precondition P
is satisfied, after executing C the postcondition Q will be satisfied.
This can be used to build up in a stepwise manner the correctness "proof"
of a function.

See C.A.R.Hoare's 1969 paper, "An Axiomatic Basis for Computer Programming"
http://extras.springer.com/2002/978-3-642-63970-8/DVD3/rom/pdf/Hoare_hist.pdf

You can already do the equivalent of this in Go today if you want. IMHO any
additional syntax doesn't seem to buy anything. If my guess is wrong,
perhaps Warren can try to clearly describe the exact *semantics* he wants?
[Always a good idea!]

-- 
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/AF8FBEDE-9F72-4278-9172-5AD693D07DDB%40bitblocks.com.

Re: [go-nuts] Why Discord is switching from Go to Rust

2020-02-07 Thread Bakul Shah

> On Feb 7, 2020, at 10:44 PM, Eric S. Raymond  wrote:
> 
> On the other hand, for me to have tried to port reposurgeon to Rust
> would have been a mind-numbingly stupid idea.  And that will be true of
> any application above a certain complexity of internal data-structure
> management, where having GC moves from bein convenient to an essential tool
> for holding dowb your defect rate.

Did you consider using nim? It is much closer to python. You could've even
selectively replaced python bits with nim bits based on profiling.

https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

In the past I have "rewritten" programs by simply observing their
behavior and modeling in a toy program, taking care to keep the code
as simple as possible. This allows quick evolution and pretty soon
the toy can do most everything the original program does. Not really
surprising since the new program didn't have to make the mistakes
the old program made and has the old program as a reference. I found
literal translation to be much more painful. 

-- 
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/4EB79AC2-D0D1-4A18-9B31-2438149462A7%40bitblocks.com.

Re: [go-nuts] net.conn TCP connection

2019-12-30 Thread Bakul Shah

> I am trying to understand what triggers the Csrc.Read(buf) to return 

The Read call will eventually turn into a read() system call. For TCP it will 
return as long as there is at least one byte in the kernel's receive buffer for 
this connection, or if the buffer give to read() is filled up, or the 
connection is closed.

Do you know about ReadAtLeast? Read its documentation:

go doc io.ReadAtLeast

For example the following code will return exactly 32k bytes or return with an 
error.

buf := make([]byte, 32*1024)
...
n, err := io.ReadAtleast(Csrc, buf, len(buf))


I am guessing this may be what you want but your requirements are rather vague 
so I'm not sure. It'll help if you can show us some pseudo code that precisely 
describes what you expect to happen, possibly with pre and post conditions (but 
if ReadAtLeast is what you want, don't bother!).

> On Dec 29, 2019, at 7:20 AM, Ron Wahler  wrote:
> 
> Jake,
> 
> Thanks for the reply. Csrc.Read is what I was referring to as the connection 
> standard read, should not have used the words "standard read" sorry about 
> that. The problem I am trying to solve is reading an unknown amount of byte 
> data.  I am trying to understand what triggers the Csrc.Read(buf) to return 
> when I send say 3 bytes to it with a client, I also keep the connection open 
> and send a few bytes of characters with the netcat tool, the Csrc.Read 
> returns, but the snip it below that with ReadAll does not return. I am trying 
> to understand the underlying behavior of what triggers a return with the data 
> in these two calls ?
> 
> on this read :
> 
> Csrc net.Conn
> 
>  buf := make([]byte, 1024*32)
> 
>  // READ FROM CLIENT
> 
> 
>  nBytes, err := Csrc.Read(buf)
> 
> 
> 
> Csrc.Read(buf)  returns with a few bytes that I send to it.  It does not wait 
> for the entire allocated buf size to return. This works great, but I am 
> looking for a way to not preallocate a large buffer.
> 
> 
> 
> I am prototyping with ReadAll, see the following snip it, but when I send a 
> few bytes to this call with a client, it does not return. The documentation 
> is saying it may be  looking for an EOF which I do not send.
> 
> 
> 
> 
>   buf, read_err := ioutil.ReadAll(Csrc)
> 
> 
> thanks,
> Ron
> 
> 
> 
> 
> 
> On Friday, December 27, 2019 at 5:11:42 PM UTC-7, Ron Wahler wrote:
> I am looking for a net.conn standard read that would return a data buffer the 
> exact size of the read. I am trying to read an unknown amount of byte data 
> from the connection. With the read i am using I am required to pre-allocate a 
> buffer and pass that buffer to the read. I am looking for a read that works 
> more like  the ReadString , but is for a byte slice.
> 
> // I want something similar to this read that returns the read string into 
> the message string.
>  message, err := bufio.NewReader(ServerConn).ReadString('\n')
> 
> if ( err != nil ){
> 
> fmt.Println("RELAY: ERROR:  Reg Message read err:", 
> err)
> 
> return 
> 
> }
> 
> 
> 
> 
> 
> // had to preallocate a buffer, but I want a read to return me a buffer so I 
> don't have to guess how big to make it.
> 
> 
>  buf := make([]byte, 1024*32)
> 
>  // READ FROM CLIENT
> 
> 
>  nBytes, err := Csrc.Read(buf)
> 
> 
> 
> 
> 
> Is this not possible, I have not seen any examples that would indicate that 
> there is a standard library that would do something like what I am looking 
> for.
> 
> 
> 
> thanks,
> 
> Ron
> 
> 
> -- 
> 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/cd1f26d6-72aa-4239-83f2-18dc6220c2db%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/E2A1F28A-E0C1-40EA-AE53-90220F9F68E8%40bitblocks.com.

Re: [go-nuts] Разбить массив чисел на два массива

2019-12-01 Thread Bakul Shah

On Dec 1, 2019, at 1:06 PM, Harald Weidner  wrote:
> 
> Hello,
> 
>> I'm not sure if that is a good idea 
>> https://play.golang.org/p/Mj77pgsaVsB
> 
> This is why three-index slices were added in Go 1.2.
> 
> https://play.golang.org/p/_sJ9OKWsvMz
> 
> https://golang.org/doc/go1.2#three_index

Unfortunately a[i:j:k] acts exactly like a[i:j] if i+k >= cap(a)
and appending to subslice can mutate the underlying slice.

See https://play.golang.org/p/ppWob2yJDiS

-- 
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/024223E8-0EDE-485B-929C-A14FA42A96FF%40bitblocks.com.

Re: [go-nuts] C variadic macro equivalent in Golang?

2019-11-30 Thread Bakul Shah

func PR(f string, a ...interface{}) {
if d { return }
fmt.Fprintf(os.Stderr, f, a...)
}

Add appropriate imports. 


> On Nov 30, 2019, at 12:08 PM, minfo...@arcor.de wrote:
> 
> C allows comma-separated argument lists via variadic macros. Whereas AFAIK 
> golang allows only variadic arguments of the same type.
> (Please excuse if I am wrong, I am considering myself a golang newbie)
> 
> C demo program that prints:   -- -- 1 and 1 1 and 1
> 
> // ## C variadic macro test
> 
> #include 
> 
> #define PR(...) if(df){printf(__VA_ARGS__);\
> if(ef)fprintf(stderr,__VA_ARGS__);}
> 
> // Flags
> int df=1, ef=1;
> 
> int main(void) {
>   PR("-- ");
>   PR("%d and %d ",df,ef);
> }
> 
> // ## End
> 
> How would one implement an equivalent PR(...) "function" in 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/e36eb032-ffbc-4b26-8c41-f76aa6dcdd00%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/37328E01-C01F-47EE-B4E1-CB7357CD2986%40bitblocks.com.

Re: [go-nuts] Preprocessing "go" statements with preserved semantics

2019-11-08 Thread Bakul Shah

There is Massimiliano Ghilardi’s gomacro Github.com/cosmos72/gomacro

Note that in case of untyped constants, there is no need to use temps so your 
idea can still work.

>> On Nov 8, 2019, at 9:30 AM, Michael Jones  wrote:
> 
> Alas. Thus the need for and glory of macros, hold/uneval, and backtick in 
> LISP. (Problems solved in the 1970s)
> 
>> On Fri, Nov 8, 2019 at 9:08 AM André Eriksson  wrote:
>> That works in simple cases, but does not work when the expression is an 
>> untyped constant, like 1 or nil. In the case of 1 the variable will get a 
>> concrete type of int, while fn may accept a float32, or even a private type 
>> that cannot be named in the current package.
>> 
>>> On Friday, November 8, 2019 at 5:51:10 PM UTC+1, Michael Jones wrote:
>>> If expr was evaluable in the original code then why not rewrite in place 
>>> after assigning temporaries?
>>> 
>>> go fn(e1,e2)
>>> 
>>> {
>>> t1,t2 := e1,e2
>>> go func() {
>>>   defer instrument()
>>>   fn(t1,t2)
>>> }
>>> 
>>> 
 On Fri, Nov 8, 2019 at 8:38 AM André Eriksson  wrote:
 I am working on a type of Go preprocessor that rewrites source code to add 
 additional instrumentation to certain types of statements.

 One such statement is the go statement. I would like to instrument the 
 newly created goroutine, injecting some instrumentation code at the start 
 and finish of the goroutine.

 In the simple case, the rewrite is straightforward:

 go fn()

 becomes

 go func() {
defer instrument()()
fn()
 }()

 However this approach does not work when fn takes parameters.
 If we were to rewrite go fn(expr) into the equivalent form above:

 go func() {
defer instrument()()
fn(expr)
 }()

 the semantics change, since in the rewrite expr gets evaluated inside the 
 newly created goroutine, which can change the behavior and introduce data 
 races.

 My attempts to address this have not been particularly fruitful.

 One cannot pass in expr as an argument to the closure, because the type of 
 the expression may not have a valid name in the current package (for 
 example if expr evaluates to a private type in some other package). 

 Similarly, if expr is a constant expression (like 1 or nil) the type may 
 depend on the corresponding parameter in fn’s signature.

 The only semantics-preserving rewrite I can think of revolves around using 
 package reflect, and rewriting like so:

 go func(fn reflect.Value, vals …reflect.Value) {
defer instrument()
fn.Call(vals)
 }(reflect.ValueOf(fn), reflect.ValueOf(expr))

 As far as I understand, this should be semantics-preserving, although with 
 a slight performance cost. (Though I imagine the cost of a 
 reflection-based call is dwarfed by the cost of spawning a goroutine.)

 Unfortunately this also comes with a major downside: the rewritten code 
 does not typecheck identically to the original code. Ideally I would like 
 the rewritten form to cause identical typechecking failures to the old 
 code, so that these errors are caught at compile time without requiring a 
 separate typechecking pass for the original code.

 Am I correct in the above reasoning? Can anyone think of a way to do this 
 sort of rewrite in a semantics-preserving and typechecking-preserving way? 

 -- 
 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/a92641f3-2eda-4d4a-ab02-d2b40e3bde75%40googlegroups.com.
>>> 
>>> 
>>> -- 
>>> Michael T. Jones
>>> michae...@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/ec41a345-163f-4a8a-a24f-b868def081a0%40googlegroups.com.
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@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/CALoEmQxe--frSeHfKo822bKhWStJoQdJpkNdAYM6zTPLUuZ%2BAg%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

Re: [go-nuts] P-local/M-local storage for goroutines?

2019-07-23 Thread Bakul Shah

Instead of starting new goroutines, send requests to existing goroutines via a 
channel.
In effect you are simulating an N core processor with per code local caches and 
one shared cache so you can look at how processors manage cache.
Just create N goroutines at the start and profile to see what happens. If 
necessary you can adjust the number of goroutines as per load.

Note the cost of managing LRU. If there is no clear pattern of accessing 
similar items, you may be better off using random replacement. As an example 
you can use LRU for smaller local caches and random for the global cache.

But if I were you I'd spend time on understanding access patterns before 
anything else. If I have no idea on the pattern, I'd pick the simplest 
implementation and evolve it based on profiling. In other words do not assume 
that "greatly reduce the contention for global lru list" is the right thing to 
do *unless* profiling tells you so.

> On Jul 23, 2019, at 7:49 PM, Zihan Yang  wrote:
> 
> Thanks for the example code, this is a possible solution. But my goroutine is 
> not long-running. More specifically, each goroutine performs some IO, then 
> returns. Next time, there might be another goroutine accessing the same file.
> 
> One workaround is to return the local storage back to CacheManager, but is 
> involves contention on CacheManager, and adds the complexity of CacheManager.
> 
> 在 2019年7月24日星期三 UTC+8上午1:48:40，Michael Jones写道：
> The simple, common way--if I understand you need correctly--is to launch a 
> method goroutine.
> 
> type CacheManager struct {
> // things a worker needs to know, such as the global cache, the specific 
> worker's local cache, etc.
> }
> 
> func master() {
>   for i := 0; i < workers; i++ {
>   m := new(CacheManager)
>   m.x = y // set up your thread local storage
> :
>   go m.Worker()
>   }
> }
> 
> Unfortunately this does not seem to be in any intro guides, which pushes 
> people to complicated workarounds.
> 
> On Tue, Jul 23, 2019 at 10:22 AM Zihan Yang > wrote:
> I am trying to implement an LRU cache. Several global lru lists could be 
> accessed concurrently by multiple goroutines, which could be a disaster in a 
> machine with 24 or more cores.
> 
> 
> 
> Therefore, it would be great if I can add the item to P-local storage and 
> flush the batched item into the lru list as a whole. This should greatly 
> reduce the contention for the global lru list.
> 
> 
> 
> How can I do it? I saw some related github issues, #8281 
>  and #21355 
> , which leads me to a project 
> called gls , but the code seems too much to 
> integrate into my project (actually I'd better not include any third-party 
> package to avoid potential law issues). Is there any built-in way to achieve 
> 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 golan...@googlegroups.com <>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/c79d3801-2f03-43fd-8dd8-35904b481341%40googlegroups.com
>  
> .
> 
> 
> -- 
> Michael T. Jones
> michae...@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/9dbe56c7-d0cd-4301-bc37-0560bcd684c4%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/2D2416B0-E395-40A1-A529-C32DC5FD3A83%40bitblocks.com.

[go-nuts] Re: [golang/go] Proposal: A built-in Go error check function, "try" (#32437)

2019-07-16 Thread Bakul Shah

And a big thank you to the Proposal Review Committee for shepherding this 
proposal & the ensuing discussion. "Open source community-wide discussion at 
its best" would be very hard to conduct without such a moderating influence. I 
learned quite a bit. Much appreciated.

Cheers,
Bakul

> On Jul 16, 2019, at 4:11 PM, Robert Griesemer  
> wrote:
> 
> Hi everyone,
> 
> Our goal with proposals like this one is to have a community-wide discussion 
> about implications, tradeoffs, and how to proceed, and then use that 
> discussion to help decide on the path forward.
> 
> Based on the overwhelming community response and extensive discussion here, 
> we are marking this proposal declined ahead of schedule 
> .
> 
> As far as technical feedback, this discussion has helpfully identified some 
> important considerations we missed, most notably the implications for adding 
> debugging prints and analyzing code coverage.
> 
> More importantly, we have heard clearly the many people who argued that this 
> proposal was not targeting a worthwhile problem. We still believe that error 
> handling in Go is not perfect and can be meaningfully improved, but it is 
> clear that we as a community need to talk more about what specific aspects of 
> error handling are problems that we should address.
> 
> As far as discussing the problem to be solved, we tried to lay out our vision 
> of the problem last August in the “Go 2 error handling problem overview 
> ,”
>  but in retrospect we did not draw enough attention to that part and did not 
> encourage enough discussion about whether the specific problem was the right 
> one. The try proposal may be a fine solution to the problem outlined there, 
> but for many of you it’s simply not a problem to solve. In the future we need 
> to do a better job drawing attention to these early problem statements and 
> making sure that there is widespread agreement about the problem that needs 
> solving.
> 
> (It is also possible that the error handling problem statement was entirely 
> upstaged by publishing a generics design draft on the same day.)
> 
> On the broader topic of what to improve about Go error handling, we would be 
> very happy to see experience reports about what aspects of error handling in 
> Go are most problematic for you in your own codebases and work environments 
> and how much impact a good solution would have in your own development. If 
> you do write such a report, please post a link on the 
> Go2ErrorHandlingFeedback page 
> .
> 
> Thank you to everyone who participated in this discussion, here and 
> elsewhere. As Russ Cox has pointed out before, community-wide discussions 
> like this one are open source at its best 
> . We really appreciate 
> everyone’s help examining this specific proposal and more generally in 
> discussing the best ways to improve the state of error handling in Go.
> 
> Robert Griesemer, for the Proposal Review Committee.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> ,
>  or mute the thread 
> .
> 

-- 
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/B10CF79C-E5DE-44C2-B96C-998DDF4E9BC1%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing gg ("gigi") your new friend

2019-07-04 Thread Bakul Shah

Very nice!

A natural great extension[1] would be language aware grep/sed/awk:
- return an enclosing parse construct after matching something
- match on a construct with some pieces wildcarded
- replace one structure with another (but based on the match)

Possible uses:
- when you change an API of a package, fix up its users
- rename variables
- replace Go1 constructs with simpler/more efficient Go2 ones.
- write generic code and replace with type specific code
- program construction (ala Beta language's fragment system)
- literate programming (tangle/weave)
- optimize code
- program analysis
- structured diff/merge

The tough part would be coming up with a simple but flexible
structured regular expression language. [Initially I had thought
this is what Rob was writing about in his "Structured Regular
Expressions" paper! So the idea is very old.] 

[1] No good deed goes unpunished :-)


> On Jul 4, 2019, at 9:10 AM, Michael Jones  wrote:
> 
> Recently I shared my Survey  
> program, saying that it was a sidestep from what I was working on but 
> interesting and hopefully useful to others. Here is the real thing, named gg, 
> that Survey was a test for. GG combines lexical analysis and Go-native 
> pattern matching to extend grep(1) for Go developers
> 
> GG is smart; the search is restricted, seeking matches only in chosen token 
> classes.  A search in number literals can match values in addition to 
> patterns: "v 255" matches the numeric value 255 in source code as 
> 0b_, 0377, 0o377, 255, 0xff, etc.  Go's linear-time regular 
> expression engine is Unicode-aware and supports many extensions: numbers in 
> identifiers are found with "gg i [0-9]" or "gg i [\d]", find comments with 
> math symbols using "gg c \p{Sm}", and Greek in strings via "gg s \p{Greek}".
> 
> GG is fast, uses all cores, understands filesystem hierarchies, archives, and 
> compression schemes, and is general like grep while focused in a new way: 
> find within package names, identifiers, types, strings, comments, and more.
> 
> Source code:
> https://github.com/MichaelTJones/gg 
> 
> Man page (all is explained here):
> https://github.com/MichaelTJones/gg/blob/master/gg.pdf 
> 
> 
> Examples: 
> 
> Search the Go 1.13 source code for strings containing Megalosaurus, but not 
> comments:
> 
> $ gg -r s Megalosaurus ~/go
> /Users/mtj/go/src/cmd/link/link_test.go:`text:"London. Michaelmas term lately 
> over, and the Lord Chancellor sitting in Lincoln’s Inn Hall. Implacable 
> November weather. As much mud in the streets as if the waters had but newly 
> retired from the face of the earth, and it would not be wonderful to meet a 
> Megalosaurus, forty feet long or so, waddling like an elephantine lizard up 
> Holborn Hill. ...
> 
> Search the Go 1.13 source code for identifiers with greek letters (but not 
> strings or comments):
> 
> $ gg -r i '\p{Greek}' ~/go
> /Users/mtj/go/src/encoding/json/encode_test.go:   A0, À, Aβ int
> /Users/mtj/go/src/math/cmplx/polar.go:func Polar(x complex128) (r, θ float64) 
> {
> /Users/mtj/go/src/math/cmplx/rect.go:func Rect(r, θ float64) complex128 {
> /Users/mtj/go/src/math/cmplx/rect.go: s, c := math.Sincos(θ)
> /Users/mtj/go/src/math/rand/rand_test.go: var χ2 float64
> :
> 
> Best to all,
> Michael
> 
> -- 
> Michael T. Jones
> michael.jo...@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/CALoEmQz-KdFaWjS%2Bfyd-QQS4LEgYmnofiZNmugnoQ7sNaG0HEA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/18AEB87E-E8A1-40BB-A63C-1DA84A607AF7%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] `on err` alternative to `try()` has traction...?

2019-07-03 Thread Bakul Shah

May be indent(1) can be taught about Go syntax rules so that it can 
"pretty-print" ala Lisp?

> On Jul 3, 2019, at 3:25 PM, Michael Jones  wrote:
> 
> Any form of restraining gofmt has my vote. One that I despise is ruining:
> 
> switch v {
> case ‘a’: doA = true
> case ‘b’: doB = true
> :
> case ‘z’: doZ = true 
> }
> 
> Just had this two days ago. So sad to see it balloon up
> 
> On Wed, Jul 3, 2019 at 11:36 AM Aston Motes  wrote:
> This proposal is not very much different from a one-liner
> 
> if err != nil {  }
> 
> It's just 10 more characters. Granted, gofmt won't leave the one-liner 
> formatted that way, but it's not much more typing and comes with the benefit 
> of not needing a new keyword.
> 
> One variation on this proposal that is a little weird is that if could in the 
> case of checking for an error omit the requirement that its argument be a 
> boolean, giving
> 
> if err {  }
> 
> Which is only 3 characters longer than on and again avoids a new keyword. I 
> believe changing the behavior of if this way should be backwards compatible.
> 
> On Wed, Jul 3, 2019 at 6:26 AM Michael Ellis  
> wrote:
> I like this. A lot.
> 
> It's clean and explicit.  The reader only needs to understand that 'on' is a 
> test for a nil value (vs 'if' which tests for boolean true).
> 
> 
> 
> On Tuesday, July 2, 2019 at 3:57:24 PM UTC-4, Liam wrote:
> This proposal has attracted modest attention from the Go team...
> https://github.com/golang/go/issues/32611
> 
> It suggests:
> 
> err := f()
> on err, 
> 
> 
> on err, return err// any type can be tested for non-zero
> on err, return fmt.Errorf(...)
> 
> on err, fmt.Println(err)  // doesn't stop the function
> on err, continue  // retry in a loop
> 
> on err, goto label// labeled handler invocation
> on err, hname // named handler invocation
> 
> 
> 
> And offers these possible extensions:
> 
> on err, os.IsNotExist(err):  
> on err, err == io.EOF:   
> on err, err.(*os.PathError): // doesn't panic if not a match
> 
> on err, : 
> on err:   // this pair provides if/else in 2 lines
> 
> 
> on err := f(),  // for assignment with single lvalue
> 
> 
> Other punctuation is possible, e.g. on (err) 
> 
> Now if we could just convince the Go gods to prototype this along with try() 
> in 1.14 :-)
> 
> -- 
> 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/decc63a5-9e65-4e96-929f-76d44cf19e14%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CANfvvbVy1iP8Un8zudCwZhkTg5dQfGCrBkN-0VmFbbK-FgD8dA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
> -- 
> Michael T. Jones
> michael.jo...@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/CALoEmQy5E5%2BK%2BKAcCvVZFJDWptNdfkAz1NrSUVa4oM%3DuQxTgOQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2B981474-49D8-4889-9C39-8BC54D2BF886%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] OOM occurring with a small heap

2019-07-02 Thread Bakul Shah

r/v4.SignSDKRequest>
>  0 0% 80.00%  1024.23kB 13.34%  
> github.com/aws/aws-sdk-go/aws/signer/v4.SignSDKRequestWithCurrentTime 
> <http://github.com/aws/aws-sdk-go/aws/signer/v4.SignSDKRequestWithCurrentTime>
>  0 0% 80.00%  1024.23kB 13.34%  
> github.com/aws/aws-sdk-go/aws/signer/v4.Signer.signWithBody 
> <http://github.com/aws/aws-sdk-go/aws/signer/v4.Signer.signWithBody>
>  0 0% 80.00%  1024.23kB 13.34%  
> github.com/aws/aws-sdk-go/service/dynamodb.(*DynamoDB).GetItemWithContext 
> <http://github.com/aws/aws-sdk-go/service/dynamodb.(*DynamoDB).GetItemWithContext>
> 
> On Tue, Jul 2, 2019 at 2:08 PM andrey mirtchovski  <mailto:mirtchov...@gmail.com>> wrote:
> What I have found useful in the past is pprof's ability to diff profiles. 
> That means that if you capture heap profiles at regular intervals you can see 
> a much smaller subset of changes and compare allocation patterns. 
> 
> On Tue, Jul 2, 2019, 10:53 AM 'Yunchi Luo' via golang-nuts 
> mailto:golang-nuts@googlegroups.com>> wrote:
> I'm not so much pointing my finger at GC as I am hoping GC logs could help 
> tell the story, and that someone with a strong understanding of GC in Go 
> could weigh in here. In the last 4 seconds before OOM, "TotalAlloc" increased 
> by only 80M, yet "HeapIdle" increased to 240M from 50M, RSS increased by 
> 810M. The numbers don't add up for me. A running sum of 80M of heap objects 
> were allocated in the time RSS increased by 10X that. If GC was completely 
> off, I still wouldn't expect this to happen, which makes me want to rule out 
> GC being blocked as a problem. Maybe there was runaway heap reservation 
> because something in my code caused a ton of fragmentation? Is that sane? The 
> heap profile lacking clues is also strange.
> 
> Regarding the possibility of a race, I forgot I do have goroutine profiles 
> captured along with the heap profiles at the time memory exploded. There are 
> only 10 goroutines running on the serving path, which rules out too many 
> concurrent requests being served (please correct me if I'm wrong). Those fan 
> out to 13 goroutines talking to the db, all of which are in 
> http.Transport.roundTrip (which is blocked on runtime.gopark so I assume they 
> are waiting on the TCP connection). All other goroutines that don't originate 
> in the stdlib are also blocked on `select` or sleeping. Our CI does run with 
> go test -race, but I'll try doing some load testing with a race detector 
> enabled binary.
> 
> Bakul, that is sound advice. I've actually been debugging this on and off for 
> a couple months now, with the help of several people, a few of which have 
> peer reviewed the code. I agree it's most likely to be some runaway code that 
> I caused in my logic, but we haven't been able to pin-point the cause and 
> I've run out of hypothesis to test at the moment. This is why I've started 
> asking on go-nuts@. The circuit breaker code was one of the first things I 
> checked, has been unit tested and verified working with load tests. Now that 
> you mention it, I actually did uncover a Go stdlib bug in http2 while doing 
> the load tests... but that's unrelated.
> 
> 
> On Tue, Jul 2, 2019 at 2:24 AM Bakul Shah  <mailto:ba...@bitblocks.com>> wrote:
> Before assuming it is the GC or something system related, you may wish to 
> verify it is *not your own logic*. Larger RSS could also be due to your own 
> logic touching more and more memory due to some runaway effect. The 
> probability this has to do with GC is very low given the very widespread use 
> of Go and the probability of a bug in new code is very high given it is used 
> on a much much smaller scale. 
> 
> This has the "smell" of a concurrency bug. If I were you I'd test the code 
> for any races, I'd review the code thoroughly with someone who doesn't know 
> the code so that I'm forced to explain it, and I'd add plenty of assertions. 
> I'd probably first look at the circuit breaker code -- things like how does 
> it know how many concurrent connections exist?
> 
> In general, any hypothesis you come up with, you should have a test that 
> *catches* the bug given the hypothesis. Elusive bugs tend to become more 
> elusive as you are on the hunt and as you may fix other problems you discover 
> on the way.
> 
> I even suspect you're looking at GC logs a bit too early. Instrument your own 
> code and look at what patterns emerge. [Not to mention any time you spend on 
> understanding your code will help improve your service; but better 
> understanding of and debugging the GC won't necessarily help you!]
> 
>> On Jul 1, 2019, at 12:14 PM, 'Yunchi Luo' via golang-nuts 
>> m

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Bakul Shah

On Jun 12, 2019, at 8:24 AM, Michael Jones  wrote:
> 
> Bakul, these are good points.
> 
> On the second, I used to always write (C/C++):
> 
> If (things are good) {
> happy case
> } else {
> sad case
> }
> 
> so the nesting was that the all-good was the first code block even when 
> multiply nested and the exceptions came later. A blunt kind of literate 
> programming that wants to talk about the 99% case first and the weird things 
> later. In Go I've converted to talk about problems all the way to the bitter 
> end and then when you run out of problems, do the job. Now that you point it 
> out, "else" falls by the wayside in this situation because it is else when 
> you did not return already. Each Go-style if-err-die "clause" is consuming an 
> else. Thank you. I had not thought of it so clearly.

It's just a different style. Here you are chopping off "sad cases" until
you are left with the big fat happy case! And by returning ASAP for the
sad cases, you reduce indentation quite a bit, which helps readability.

> 
> The first is a good point too. The debate about the ternary operator might be 
> better viewed as a completion of short variable declaration. Block scope 
> means is not possible to write...
> 
> if b {
> x := 1
> } else {
> x := 2
> }
> :
> use X
> 
> ...so the benefits of short variable declaration are lost to a choice between 
> redundancy as you show:
> 
> x := 1
> if b {
> x = 2
> }
> 
> which hides the intent -- the if b is the intent and that's not evident from 
> x := 1. The intent is "x := either 1 or 2 depending" and that is well 
> expressible only when the := is in the outer scope and the "1 or 2" are 
> expressions from an inner one being transported across the lexical boundary 
> by an operator -- the "depending" operator whatever its name or form might be.

You can almost speed-read straight line code but as soon as you
encounter if or switch (or other control flow changing part) you
have to stop and regroup. This is why (for me)

x := b? 2 : 1

is far easier to read than either

var x int
if b {
  x = 2
} else {
  x = 1
}

or worse,

x := 1
if b {
  x = 2
}


> x := {1,2}[b]

This requires evaluating both alternatives. This may not
even be possible:

x := p == nil? 10 : p.val

or may had extra side-effects:

x := {f1(), f2()}[b]

This can also a problem with

x := f1()
if b { x = f2() }



-- 
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/94BE2E16-59A0-4984-8D47-E2D3B28E6C98%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go Language Survey

2019-06-12 Thread Bakul Shah

On Jun 12, 2019, at 7:36 AM, Michael Jones  wrote:
> 
> 128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to 
> understand this better,

There are two patterns that encourage this:

x := v1
if someCond { x = v2 }

And

if someCond { return ... }

The second pattern acts sort of as a filter. Which is useful (fewer choices 
left).

The first pattern is due to a lack of C’s ?: construct. [In light of that it is 
amusing to see try as a “function” being proposed that even does a conditional 
return!]

-- 
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/44D09A2F-CCC7-492D-B06C-6D870E225283%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Allow methods on primitives

2019-06-09 Thread Bakul Shah

On Jun 9, 2019, at 7:42 AM, Michael Ellis  wrote:
> 
> On Sunday, June 9, 2019 at 9:56:43 AM UTC-4, Bakul Shah wrote:
> 
> You are almost always going to call a string's Render function 
> (as you defined it in your original post) from a parent HTMLTree 
> struct' Render(), almost never in isolation -- except perhaps some 
> tests. So one suggestion is to deal with string rendering issues 
> in the parent HTMLTree struct's Render(). Now you can still say 
> 
>   Div("", P("id=1", "When in the course of ...")) 
> 
> 
> Perhaps I'm misunderstanding, but I don't see how to make that work for tags 
> that can take both text or other elements without resorting to making the 
> content arguments of type interface{}. That's doable and the performance 
> penalty is negligible but it discards the benefit of Go's compile time type 
> checks.
> 
> For reference, I've pasted together the guts of my html rendering code, 
> defined a couple of tag functions and added a short main to illustrate what 
> I'm doing at https://play.golang.org/p/_qZ7Oyv2Foa
> 
> Any suggestions for cleanly allowing passing strings appreciated.

Actually this is a good candidate for sum-types, something I have
wanted in Go (and IMHO something that fits in well). So for example:

type Tree struct {
T, A string
C []Content
empty bool
}

type Content_ interface {
Render(b *bytes.Buffer, nindent int) error
}

type Content = Content_ | string
...
Div("", "Here's a link", A("href=someURL", "to some URL"), "and so 
on").Render(, 0)

This gives you better compile time checking and the same
convenience as using interface{}. Unfortunately

-- 
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/12A0928E-E732-44AC-B44C-F31B46C7A464%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Allow methods on primitives

2019-06-09 Thread Bakul Shah

On Jun 9, 2019, at 6:14 AM, Michael Ellis  wrote:
> 
> I'm not disputing the wisdom of Go's design. As I said at the top of the 
> initial post, I like Go the way it is and see no need for a Go 2.  
> 
> I was trying to find a clean solution to a specific use case:  nestable 
> functions that generate html.  Since new methods on primitives are not 
> allowed (for good reason as I now understand) I wanted to at least inquire 
> about the possibility of loosening the restrictions on a very specific case:  
> function args whose type is effectively a string (or other primitive).  I get 
> the point the about types being not the same in terms of Go's internal 
> bookkeeping. However, in this particular narrow case I don't see a hazard to 
> maintainability because the rule forbidding new methods on primitives 
> excludes any possibility of confusion within the body of the function.
> 
> To my mind, having to define a type equivalent to a primitive solely for the 
> purpose of implementing an interface detracts from readability.  But given 
> that there's good reason for the requirement I think being able to pass the 
> equivalent primitive as a function argument of that type seems like a 
> potentially safe way to make the code more readable.

On the flip side, when someone does
  fmt.Printf("%v", someString)
I know exactly what will be printed; it doesn't depend on the context.

You are almost always going to call a string's Render function
(as you defined it in your original post) from a parent HTMLTree
struct' Render(), almost never in isolation -- except perhaps some
tests. So one suggestion is to deal with string rendering issues
in the parent HTMLTree struct's Render(). Now you can still say

  Div("", P("id=1", "When in the course of ..."))

But you can use, e.g. Printf("%v", html.tag) and something different
occur. Another option is to have functions like Div and P accept
normal strings in convert them to application specific strings in
the function body.

In other words, the builtin types and the standard Go library provide
*no-surprises* behavior but that may not be enough for any application
specific needs and it is better to just build what you need without
changing the behavior of standard components that everyone relies on.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BEC2C543-76E5-4F0F-B97D-1FF052F62CD6%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Remind me, please, about "taking over" a socket

2019-05-30 Thread Bakul Shah

On Thu, 30 May 2019 20:10:30 -0700 Bakul Shah  wrote:
>
> You will have to use low level code like Socket(), Bind() etc. You can't
> use e.g. Dial("tcp", "192.168.1.1:smtp")

This should've been edited out since we are talking about Listen.

-- 
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/20190531031238.77959156E40C%40mail.bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Remind me, please, about "taking over" a socket

2019-05-30 Thread Bakul Shah

On Thu, 30 May 2019 17:40:55 -0700 David Collier-Brown  
wrote:
>
> My leaky brain has lost an old technique...
>
> Once upon a time, I would send an old copy of a program a SIGHUP, and it 
> would shut down a socket listening on, for example, port 25 (SMTP). A newer 
> release of the program would succeeding in binding to port 25, taking over 
> any new connection requests. When the old program closed it's last email 
> transfer, it would then exit.
>
> The idea was to update a (mail-)server implementation without losing 
> transactions.
>
> I can no longer find the code I once used, nor other people's examples, 
> much less modern Golang examples!
>
> Please tell me we haven't lost this technique (:-()

man setsockopt and look for SO_REUSEADDR/SO_REUSEPORT

You will have to use low level code like Socket(), Bind() etc. You can't
use e.g. Dial("tcp", "192.168.1.1:smtp")


Something like
err := syscall.SetsockoptInt(s, syscall.SOL_SOCKET, syscall.SO_REUSEADDR, 1)
err := syscall.SetsockoptInt(s, syscall.SOL_SOCKET, syscall.SO_REUSEPORT, 1)

https://github.com/libp2p/go-reuseport has an example.

Though IMHO such ports should be passed from an *external*
program for security purposes (your service enpoint shouldn't
be opening any ports on its own). Also makes it easier to
test.

-- 
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/20190531031037.892A0156E40C%40mail.bitblocks.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Performance comparison of Go, C++, and Java for biological sequencing tool

2019-03-06 Thread Bakul Shah

Thanks for an interesting read!

Curious to know if you guys have any estimates on the number of lines, 
development time and number of bugs for each language implementation? I realize 
this is subjective but this comparison may be quite meaningful given that the 
authors had an existing reference implementation of a sort done in CL. It is 
not often one sees real world examples of multiple implementations done by a 
small team with the same goals.

Thanks!

> On Feb 28, 2019, at 9:05 AM, 'Isaac Gouy' via golang-nuts 
>  wrote:
> 
> "We reimplemented elPrep in all three languages and benchmarked their runtime 
> performance and memory use. Results: The Go implementation performs best, 
> yielding the best balance between runtime performance and memory use. While 
> the Java benchmarks report a somewhat faster runtime than the Go benchmarks, 
> the memory use of the Java runs is significantly higher."
> 
> proggit discussion
> 
> article
> 
> 
> -- 
> 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] Is Go a single pass compiler?

2019-03-02 Thread Bakul Shah

Algol 68 allowed use before definition which would force more
than one pass but I believe many Algol 68 compilers didn’t allow
this and forced forward declarations much like in C.

I suspect “multiple pass” makes less sense for modern compilers.
When you can keep an entire program in memory, using multiple
representations, you can have many walks over the same trees.
Almost by definition an “optimizing” compiler has to go over the
same code fragment multiple times. I wonder what all the Stalin
compiler for R4RS Scheme did. It ran slow as molasses to produce
C code but this ran faster than hand optimized C code!

> On Mar 2, 2019, at 4:16 AM, Jesper Louis Andersen 
>  wrote:
> 
>> On Thu, Feb 28, 2019 at 12:46 AM  wrote:
> 
>> Thanks, Ian.
>> 
>> I remember reading in some compiler book that languages should be designed 
>> for a single pass to reduce compilation speed.
>> 
> 
> As a guess: this was true in the past, but in a modern setting it fails to 
> hold.
> 
> Andy Keep's phd dissertation[0] implements a "nanopass compiler" which is 
> taking the pass count to the extreme. Rather than having a single pass, the 
> compiler does 50 passes or so over the code, each pass doing a little 
> simplification. The compelling reason to do so is that you can do cut, paste, 
> and copy (snarf) each pass and tinker much more with the compilation pipeline 
> than you would normally be able to do. Also, rerunning certain simplify 
> passes along the way tend to help the final emitted machine code. You might 
> wonder how much this affects compilation speed. Quote:
> 
> "The new compiler meets the goals set out in the research plan. When compared 
> to the original compiler on a set of benchmarks, the benchmarks, for the new 
> compiler run, on average, between 15.0% and 26.6% faster, depending on the 
> architecture and optimization level. The compile times for the new compiler 
> are also well within the goal, with a range of 1.64 to 1.75 times slower. "
> 
> [Note: the goal was a factor 2.0 slowdown at most]
> 
> The compiler it is beating here is Chez Scheme, a highly optimizing Scheme 
> compiler.
> 
> Some of the reasons are that intermediate representations can be kept in 
> memory nowadays, where it is going to be much faster to process. And that 
> memory is still getting faster, even though at a slower pace than the CPUs 
> are. The nanopass framework is also unique because it has macro tooling for 
> creating intermediate languages out of existing ones. So you have many IR 
> formats in the compiler as well.
> 
> In conclusion: if a massive pass blowup can be implemented within a 2x factor 
> slowdown, then a couple of additional passes is not likely to make the 
> compiler run any slower.
> 
> [0] http://andykeep.com/pubs/dissertation.pdf
> 
> -- 
> 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] Go vs C speed - What am I doing wrong?

2019-02-12 Thread Bakul Shah

According to the C standard:

If the quotient  a/b  is  representable,  the
expression (a/b)*b + a%b shall equal a.

In your example, dividing x by -1 would make x +2147483648,
which is not representable in int32_t. May be this is
why -2147483648/-1 also exceptions out?

Nitpicking: C's % is a remainder operator, not modulus.

> On Feb 12, 2019, at 4:23 PM, Nigel Tao  wrote:
> 
> On Mon, Feb 4, 2019 at 5:34 AM Miki Tebeka  wrote:
>> A bit of profiling shows that the modulo operator takes most of the time:
> 
> C's modulo operator is faster, but can crash if you look at it funny.
> 
> $ cat x.c
> #include 
> 
> int main(int argc, char** argv) {
>  int x = -2147483648;
>  int y = -1;
>  printf("x=%d\n", x);
>  printf("y=%d\n", y);
>  printf("m=%d\n", x % y);
>  return 0;
> }
> $ gcc x.c && ./a.out
> x=-2147483648
> y=-1
> Floating point exception
> 
> Compare it to the output of https://play.golang.org/p/Yj2RZmB7ZRI
> 
> Yes, both the Go code and the C code will panic if y is zero. Still,
> "-2147483648 % -1" has a sensible mathematical definition (zero), and
> C fails to calculate 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] Modules. A "new" system.

2019-02-05 Thread Bakul Shah

I hope bignums will be added to Go2 as a builtin type!

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

Re: [go-nuts] Go vs C speed - What am I doing wrong?

2019-02-03 Thread Bakul Shah

Suggestion: specify all relevant details as we don’t know what kind of machine 
you have.

I suspect your machine is a 64bit word size machine. C ints are typically 4 
bytes even on 64bit word size machines. Go ints are 8 bytes on these machines.

Suggestion2: look at the generated assembly language code for each program. 
Making sense of compiler output is a very useful skill to learn for 
benchmarking (& more).

> On Feb 3, 2019, at 10:22 AM, Miki Tebeka  wrote:
> 
> Hi,
> 
> I'm comparing two loops in Go and C. The Go code on my machine is about 3 
> times slower than C. I know C can be faster but didn't think it'll be that 
> faster. Any ideas what's making the Go code slower?
> 
> You can see the code at https://github.com/tebeka/go-c-loop
> 
> Go Code:
> package main
> 
> 
> import (
>  "fmt"
>  "os"
>  "strconv"
>  "time"
> )
> 
> 
> func main() {
>  n, _ := strconv.Atoi(os.Args[1])
>  m, _ := strconv.Atoi(os.Args[2])
> 
> 
>  sum := int(0)
>  start := time.Now()
>  for i := 0; i < 1000; i++ {
>  if i%n != m {
>  sum += n
>  }
>  }
> 
> 
>  fmt.Println(time.Now().Sub(start).Seconds(), sum)
> }
> 
> 
> 
> C Code
> #include 
> #include 
> #include 
> 
> 
> 
> 
> int main(int argc,char** argv) {
> unsigned long long ull0,ull1;
> unsigned int sum=0,n,m;
> 
> 
> sscanf(argv[1],"%d",);
> sscanf(argv[2],"%d",);
> 
> 
> ull0 = __rdtsc();
> for(int i=0; i<1000; i++) {
> if(i%n != m) {
> sum += n;
> }
> 
> 
> }
> 
> 
> ull1 = __rdtsc();
> printf("%f %d\n",(ull1-ull0)/2.1e9,sum);
> }
> 
> 
> 
> -- 
> 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] Existing code for order-preserving concurrent work queue?

2019-01-31 Thread Bakul Shah

Here's a slightly different way of looking at this:

It is known that if you have N servers, a single queue is better than
N separate queues, so as to avoid the situation where you have an
idle server with an empty queue and a waiting customer in a queue
for a busy server. So the only other task is how to rearrange the outputs
in the same order. An interface as follows may help:

type Any2SerialQ interface { // Any order in, serial order out
Put(n uint, item interface{})
Get() interface{}
}

Where Put() can be in any order (as dictated by n) but Get() is always
in sequence.

The peak buffer use depends on the laggard. If item N is taking a long
time and further K items have completed, their results must be held
until N finishes.

Note that the problem is somewhat analogous to reconstituting a TCP
stream when packets arrive out of order.

> On Jan 31, 2019, at 4:06 AM, roger peppe  wrote:
> 
> On Thu, 31 Jan 2019 at 00:06, Michael Jones  > wrote:
> note that my code sidesteps this problem generally
> 
> I'm not sure that that's true. Although your code mitigates the problem 
> somewhat,
> it's still possible for a one slow worker to block the others. You've added 
> 512*NumCPU/2
> buffer slots, but in general it's not possible to order results and provide 
> avoid unnecessary
> blocking without having N buffer slots. In your code, assume 4 CPUs and that 
> work items 0
> and 2 take 1s and all other work items take 1ms. If we've got 5000 items in 
> total,
> the total time taken will be 2.002498s instead of the ideal time (~1s+2499µs).
> 
> https://play.golang.org/p/5Ty6pgpmZ0w 
> 
> Here's a kind of hybrid approach. It still serializes, but it makes as good a 
> use of the buffer
> space as it can - it won't block until a slow item is at least bufSize items 
> behind the
> most recently processed item:
> 
> https://play.golang.org/p/PP9NSJuLeEK 
>  
> On Wed, Jan 30, 2019 at 3:48 PM roger peppe  > wrote:
> On Wed, 30 Jan 2019 at 20:07, 'Bryan Mills' via golang-nuts 
> mailto:golang-nuts@googlegroups.com>> wrote:
> The code to sequence the results using a channel is not much more verbose.
> 
> That not only avoids the library dependency, but also makes the peak memory 
> consumption for the results O(runtime.NumCPU()), instead of O(N) with the 
> number of tasks, and allows the output to be streamed instead of buffered to 
> a slice.
> 
> https://play.golang.org/p/zkBjxlcvESe 
> 
> Nice! In practice though, I've usually found that I do want to keep the 
> results around or I don't care about the order at all, so the parallel 
> package works OK.
> 
> I'd point out one down side to the sequencing approach - one very slow work 
> item can block the others. For example, NProc is 4, the first item takes 200 
> milliseconds to process and all the others take 1 millisecond, then the first 
> 4 workers have started, none more will be started until the first has, so the 
> overall time will be quite a bit longer (249ms) than if they were all allowed 
> to proceed irrespective of order (200ms).
> 
> 
> -- 
> 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 
> .
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@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 
> .
> 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] Memory usages

2019-01-30 Thread Bakul Shah

I think computing memory use of any *constant* is not straightforward and 
probably not worth it. Even a typed constant may only exist in an instruction 
stream. For instance "var x int64 = 42" may compile down to a single 
instruction (or more, depending on the underlying architecture). Or there may 
be a "constant pool" for larger constants such as strings and structs or 
arrays. 

> On Jan 30, 2019, at 6:55 PM, 伊藤和也  wrote:
> 
> OK, I understand it somehow but I want to make sure my understanding is 
> correct.
> 
> There are two types of constant "untyped constant" and "typed constant".
> 
> 1. An untyped constant has a size but it's not specific which means an 
> untyped constant takes some memory.
> fmt.Println(100)
> 
> 2. A typed constant has a specific size which means a typed constant takes a 
> specific amount of memory.
> fmt.Println(int(100))
> 
> Is my understanding correct?
> 
> 2019年1月31日木曜日 9時05分32秒 UTC+9 伊藤和也:
> An interger constant is "int" type and takes "8" bytes memory on 64-bit 
> system.
> 
> fmt.Println(unsafe.Sizeof(100)) // 8
> fmt.Println(reflect.TypeOf(100)) // int
> 
> and an "int32" type value takes "4" bytes.
> 
> var num int32
> fmt.Println(unsafe.Sizeof(num)) // 4
> 
> So in this case below, Is the memory usage "12" bytes in total? (Question 1)
> 
> var num int32 = 100
>  |  |
> 4 bytes  +  8 bytes = 12 bytes
> 
> and in this case below, Is the memory usage "16" bytes in total? (Question 2)
> because the integer constant "100" is "8" bytes first then it's converted to 
> "int32" which is "4" bytes.
> 
> var num int32 = int32(100)
>  | | |
>4 bytes + 4 bytes + 8 bytes = 16 bytes  
> 
> -- 
> 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] What does a deadlock mean in golang?

2019-01-30 Thread Bakul Shah

On Wed, 30 Jan 2019 12:21:46 -0800 Tom Mitchell  wrote:
>
> On Tue, Jan 29, 2019 at 12:55 AM =E4=BC=8A=E8=97=A4=E5=92=8C=E4=B9=9F  a.ito.dr...@gmail.com> wrote:
>
> > I know the general meaning of a deadlock, but I don't know the meaning of
> > a deadlock in golang.
> >
>
> Good question...
> A classic and now hard to find reference for a deadlock is "Operating
> System Principles (Prentice-Hall Series in Automatic Computation) by Per
> Brinch Hansen"
>

This is the classic paper on Deadlocks:

http://www.ccs.neu.edu/home/pjd/cs7600-s10/Tuesday_January_26_01/p67-coffman.pdf

@article{Coffman:1971:SD:356586.356588,
 author = {Coffman, E. G. and Elphick, M. and Shoshani, A.},
 title = {System Deadlocks},
 journal = {ACM Comput. Surv.},
 issue_date = {June 1971},
 volume = {3},
 number = {2},
 month = jun,
 year = {1971},
 issn = {0360-0300},
 pages = {67--78},
 numpages = {12},
 url = {http://doi.acm.org/10.1145/356586.356588},
 doi = {10.1145/356586.356588},
 acmid = {356588},
 publisher = {ACM},
 address = {New York, NY, USA},
}

-- 
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 performance comparation of Golang and Java

2019-01-25 Thread Bakul Shah



> On Jan 24, 2019, at 8:48 PM, Ian Lance Taylor  wrote:
> 
> On Thu, Jan 24, 2019 at 7:01 PM Karthik Krishnaswamy
>  wrote:
>> 
>> I am just curious to understand what is the best possible way to increase 
>> the execution speed of this particular program ? I am still learning go 
>> though :)

General advice to Karthik: use micro-optimizations only as the last resort. 
Improve developer's execution speed :-)

> To speed up that particular program, don't use recursive Fibonacci.
> The recursive function that you wrote has complexity O(2 ** N).  Write
> a simple loop, complexity O(N).

There is a O(log N) recursive algorithm but probably not worth it when you can 
only compute 64bit size fibonacci numbers (up to 91).

> Ian
> 
> 
>> On Fri, Jan 25, 2019 at 8:26 AM Ian Lance Taylor  wrote:
>>> 
>>> On Thu, Jan 24, 2019 at 6:21 PM Topget  wrote:
 
 I have tested several simple functions with Golang and Java. To my 
 surprise, Java sometimes is faster than Golang（especially in recursive 
 function and some function in standard library such as math/rand.Rand）. I 
 wonder why. Here is some code I used for test and the result.
>>> 
>>> Because goroutines start with a small stack that grows as needed,
>>> deeply recursive functions will tend to have somewhat worse behavior
>>> the first time they are called.
>>> 
>>> Ian
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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] This Makes No Sense

2019-01-22 Thread Bakul Shah

This is kind of like tic-tac-toe! The first player has an advantage. Gomoku's 
swap2 rule makes it fairer and more interesting!

Also a good game to practice writing alpha-beta pruning search (for playing 
with a computer)!

Representing the board as two sets of n^2 bitmaps would speed things up and 
allow searching more plys (turns) ahead in a given time period. Two because you 
need to represent black, white, empty states for each square. Sets make it 
easier/faster to check for "better" placements.

I think Marcus is really talking about checking for valid row, column 
numbers[1]. But this valid row/column index problem can be trivially solved by 
simply doing a modulo operation! That is, if the user types 45, 45, treat it as 
if he typed 1, 1 (for a 15x15 board, rows and columns are numbered 0..14).

[1] I suspect this is a homework problem.

> On Jan 22, 2019, at 11:37 AM, Michael Jones  wrote:
> 
> I could not decode the question, so I just wrote a program to do it all. 
> John, does this help? 
> Change the constants for whatever board geometry and n-in-a-row victory rule 
> you want.
> 
> https://play.golang.org/p/JtouiOlkGCO 
> 
> P.S. the progression from 3 to 4 to 5 in a row is a great way to teach kids 
> important mental skills. 
> 
> On Tue, Jan 22, 2019 at 7:39 AM Marcus Low  > wrote:
> I meant "constant space overhead", sorry.
> 
> On Tuesday, January 22, 2019 at 11:38:02 PM UTC+8, Marcus Low wrote:
> As Justin Israel said, you can probably scan them to int and test them as 
> ints.
> 
> However, if you really need them to be parsed as string, this will help your 
> runtime, at the cost of constant overhead:
> var (
>   valueSet = map[string]struct{}{
> "1":nil,
> "2":nil,
> "3":nil,
> 
> "15":nil,
>   }
> )
> 
> func checkValue(s string) bool {
>   _, ok := valueSet[s]
>   return ok
> }
> 
> func fix() {
>   if checkValue(x) {
> 
>   }
>   
> }
> 
> 
> 
> On Tuesday, January 22, 2019 at 6:40:52 AM UTC+8, John wrote:
> 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 
> .
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@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 
> .
> 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] Re: Suggestions for layout/structure/coding-patterns for GUI applications in Go?

2019-01-12 Thread Bakul Shah

On Sat, 12 Jan 2019 15:55:01 -0800 David Collier-Brown  
wrote:
>
> I'm pleasantly mature (born in 1644), but I still don't understand 
> javascript GUIs (;-))

Amazing.

-- 
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] C++ 11 to Golang convertor

2019-01-07 Thread Bakul Shah

On Sun, 06 Jan 2019 17:01:20 -0500 "Eric S. Raymond"  wrote:
>
> A simple, possibly correct LR parser for C11
>
> http://gallium.inria.fr/~fpottier/publis/jourdan-fpottier-2016.pdf

This paper says its lexer+parser is about 1000 lines, which
doesn't include the preprocessor. For comparison, subc (a
compiler for a self compiling subset of C) is under 5K lines,
including a preprocessor. It is a recursive descent compiler
which may be easier to grok. Best of all, there is an
associated book called "practical compiler construction" (for
a slightly older compiler). There is even a Go version of
subc! subc is completely public domain.
https://www.t3x.org/subc/index.html
May be worth checking subc out (though it will have to be
extended to cover missing features such as goto, typedef...)

The other suggestion I have is to figure out how to map
individual C constructs to Go and not try mapping idiomatic C
code to idiomatic Go code. The former is a hard enough
problem as it is. Then may be you can convert robotically
translated code to idiomatic code (sort of what the Go folks
must've done/are doing). This way you can internalize most of
the translation scheme before writing a single line of
production code. And it is much easier to change the xlation
scheme while you have just a paper design! [I once spent a
bunch of tine on writing a Beta language to C translator and
followed this path]

-- 
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] What are the reasonable reasons to use pointers?

2019-01-02 Thread Bakul Shah

On Tue, 01 Jan 2019 22:56:06 -0800 Ian Lance Taylor  wrote:
> On Tue, Jan 1, 2019 at 6:42 PM Bakul Shah  wrote:
> >
> > On Tue, 01 Jan 2019 03:34:34 -0800 =?UTF-8?B?5LyK6Jek5ZKM5Lmf?= 
> >  wrote:
> > >
> > > What are the reasonable reasons to use pointers? Are pointers neseccary?
> >
> > Pointers are not necessary as a programming language feature
> > but are necessary in implementing a programming language.  As
> > an example, Scheme doesn't have pointers.
>
> Scheme doesn't have pointers in the same sense that Java doesn't have
> pointers: in both Scheme and Java all non-primitive types are
> represented using pointers.  So while it's true that the languages
> don't have pointers, you still have to understand that you are always
> dealing with reference types.

True but I'd rather keep pointers seperate from shared state.
There are other languages such as k that do pass compound
objects by value. Thus in k

x:1 2 3 4
f:{[v]v[1]:5} // similar to (define (f v) (vector-set! v 1 5))
f x

does *not* modify x. [It does this by using copy-on-write]

-- 
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: go for robotic control, walking balance, quad flight control

2019-01-01 Thread Bakul Shah

On Tue, 01 Jan 2019 15:40:41 -0800 Pat Farrell  wrote:
>
> On Monday, December 31, 2018 at 4:19:50 PM UTC-5, minf...@arcor.de wrote:
> >
> > So perhaps you should saddle your horse backwards, and then decide if 
> > Golang as front-end development language
> > is really the right choice for you. And then Golang doesn't treat complex 
> > matrix algebra well...
> >
> > And you'll need some sort of simple GUI for simulation, loop monitoring 
> > and control parameter adaptation...
> >
>
> Go is a terrible choice, IMHO, for any front-end stuff.
> I see zero reason to use go for the GUI, simulation stuff. 

For a summer intern prject we used Go for GUI as well as
simulation with very good results. We simulated N cars driving
on a generated street layout with traffic lights at
intersections. Each light was a separate goroutine and a car
was simulated with a set of goroutines.  The GUI was a
separate program providing a zoomable view of the roads and
moving cars.

FWIW, my advice is to find out for yourself what works and
what doesn't. RPi3 would be a good choice. If need be, you can
write a small C program (or kernel module) to deal with any
tighter timing controls. There are some go libraries for GPIO
on RPi that may be worth checking out.

-- 
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] What are the reasonable reasons to use pointers?

2019-01-01 Thread Bakul Shah

On Tue, 01 Jan 2019 03:34:34 -0800 =?UTF-8?B?5LyK6Jek5ZKM5Lmf?= 
 wrote:
>
> What are the reasonable reasons to use pointers? Are pointers neseccary?

Pointers are not necessary as a programming language feature
but are necessary in implementing a programming language.  As
an example, Scheme doesn't have pointers.

-- 
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] if/switch statements as expressions

2018-12-20 Thread Bakul Shah

On Thu, 20 Dec 2018 13:13:04 -0800 Michael Jones  
wrote:
>
> There is an inelegant but highly effective "hack" in GCC/G++ in thuas area.
> Since C/C++ are expression language as Rob put it (e.g. a statement like
> "3" compiles where in Go it fails with "3 evaluated but not used") GCC took
> this a step further and implemented that the last expression evaluated in a
> block is the value of that block. This makes "x = {if (a>b) then 7 else
> 2;}" do what "x = (a>b)?7:2" means but allows any and all code in there.
> Won't work in Go because of "3 evaluated but not used" but I've used it
> gratefully in macro situations in the past.

Algol-68 allowed this by design. No hack required! The value
of a sequence of expressions was the last expression. It also
allowed if and switch expressions. And it allowed much more
concise alternate syntax for some constructs but with exactly
the same semantics. Among other things this meant the language
had to have union types.
  x := IF cond THEN 1 ELSE "foo" FI
or
  x := (cond | 1 | "foo")
is a perfectly legal expression. So is this:
  CASE x IN
(INT i): foo(i),
(STRING s): bar(s),
OUT error(x)
  ESAC

In my view Go could've been more of an expression language
without losing any of its strong points.

-- 
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] Pure functions and Go2

2018-12-14 Thread Bakul Shah




> On Dec 14, 2018, at 1:17 PM, Michael Jones  wrote:
> 
> I don't actually prefer marking a func as pure. best if it is a discovered 
> attribute during compilation.

You said
> If a function was labeled as pure ("pure func ...") the compiler would not 
> even need think hard

I thought you were advocating this. Compilers can already discover
non-mutating functions with some analysis. But the more such tricks a
compiler discovers, the slower it becomes So there is some value
in helping the compiler by marking functions as pure but I think the
cost of doing so is language complexity that a user has to face.

Personally I'd rather see Go become a better higher level language.

> 
> Not sure what you mean about complexity. The compiler would not be obligated.
> 
> 
> On Fri, Dec 14, 2018 at 1:12 PM Bakul Shah  wrote:
> On Dec 14, 2018, at 12:50 PM, Michael Jones  wrote:
> > 
> > Have been thinking about pure functions (in the Scheme sense of no 
> > externalities other than constants and pure functions and no side effects) 
> > in the context of weak metaprogramming and compiler optimization. Here is 
> > the idea.
> 
> Scheme does permit impure functions. Such functions by *convention* have
> a "!" suffix but there is nothing special about that.
> 
> > :
> > a := math.Sin(0.1234)
> > :
> > b := bits.RotateLeft64(0x12345678, 7)
> > :
> > func myFunc(x int) byte { return x>>2 }
> > :
> > c := myFunc(42):
> > 
> > There is no absolute reason why a, b, and c could not be evaluated at 
> > compile time. 
> > 
> > There are many practical reasons why it cannot be done today.
> > 
> > If a function was labeled as pure ("pure func ...") the compiler would not 
> > even need think hard, and if purity were a reflectable attribute, then it 
> > is imaginable that compiling a function invocation could be:
> 
> This would complicate the language unnecessarily in the name
> of optimization. Next on the slipper slope would be declaring
> parameters "pure" and then having two versions of things. e.g.
> 
> func intReduce(func(x, y int)int, []int) int
> 
> This can be evaluated at compile time if the given func is pure.
> Not worth it, IMHO.
> 
> > 
> > "if package is a standard one (like math) and the function is a pure one, 
> > then call func on argument and use the result here" 
> > 
> > Doing this for user packages brings up deeper issues and is harder.
> > 
> > -- 
> > Michael T. Jones
> > michael.jo...@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.
> > For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Michael T. Jones
> michael.jo...@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.
> 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] Pure functions and Go2

2018-12-14 Thread Bakul Shah

On Dec 14, 2018, at 12:50 PM, Michael Jones  wrote:
> 
> Have been thinking about pure functions (in the Scheme sense of no 
> externalities other than constants and pure functions and no side effects) in 
> the context of weak metaprogramming and compiler optimization. Here is the 
> idea.

Scheme does permit impure functions. Such functions by *convention* have
a "!" suffix but there is nothing special about that.

> :
> a := math.Sin(0.1234)
> :
> b := bits.RotateLeft64(0x12345678, 7)
> :
> func myFunc(x int) byte { return x>>2 }
> :
> c := myFunc(42):
> 
> There is no absolute reason why a, b, and c could not be evaluated at compile 
> time. 
> 
> There are many practical reasons why it cannot be done today.
> 
> If a function was labeled as pure ("pure func ...") the compiler would not 
> even need think hard, and if purity were a reflectable attribute, then it is 
> imaginable that compiling a function invocation could be:

This would complicate the language unnecessarily in the name
of optimization. Next on the slipper slope would be declaring
parameters "pure" and then having two versions of things. e.g.

func intReduce(func(x, y int)int, []int) int

This can be evaluated at compile time if the given func is pure.
Not worth it, IMHO.

> 
> "if package is a standard one (like math) and the function is a pure one, 
> then call func on argument and use the result here" 
> 
> Doing this for user packages brings up deeper issues and is harder.
> 
> -- 
> Michael T. Jones
> michael.jo...@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.
> 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] Package Stutter

2018-12-03 Thread Bakul Shah




> On Dec 3, 2018, at 8:08 AM, Robert Engels  wrote:
> 
> I understand that, and when working in code that uses both types, which is 
> probably limited, you fully qualify. This is pretty standard stuff in the 
> enterprise world, as well architected solutions are segmented, so you only 
> encounter this problem at the integration points, and that code is qualified.

If you import another package where you are already using a dot import,
you are already using Employee. You then decide to change the new import
to dot import, at which point you discover the name clash. Now you have
to qualify all existing Employee references with the first package. So
a new import forces you to edit code that may have nothing to do with the
new import.

If you don't do this, you will have Employee references (to the first pkg)
that are not qualified and some qualified ones. This will confuse things
because someone (or you, a few months later) will then go looking for
the Employee defn in your own package and not find it.

It can all be made to work but why complicate things when a simple rule
suffices?

> 
> You have a similar problem if both applications have a model package. Now you 
> need to override the import on one of them. No difference IMO. 
> 
>> On Dec 3, 2018, at 10:03 AM, Bakul Shah  wrote:
>> 
>>> On Dec 3, 2018, at 6:52 AM, Robert Engels  wrote:
>>> 
>>> I think people are misunderstanding my equal footing need. I don’t mean for 
>>> all applications, I mean for a application. 
>>> 
>>> Here’s another example. You have a enterprise payroll application. You have 
>>> a model package. You have model.Employee. Having to use model.Employee 
>>> throughout the application is noise. Everyone working on the application 
>>> knows that Employee means model.Employee. It is part of the language (dsl 
>>> in a way) for that application. 
>> 
>> Now suppose you have to write a application that
>> has to access payroll as well as employee performance
>> review, health insurance, expense reporting, connect
>> to 3rd parties for special discounts for various things,
>> etc. Each of these subsystems may have their own
>> definition of Employee (which may be stored in their
>> own databases). This list may grow over time and you
>> don't want to have to recompile and retest *existing*
>> packages by changing some central Employee type.
> 

-- 
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] Package Stutter

2018-12-03 Thread Bakul Shah

On Dec 3, 2018, at 6:52 AM, Robert Engels  wrote:
> 
> I think people are misunderstanding my equal footing need. I don’t mean for 
> all applications, I mean for a application. 
> 
> Here’s another example. You have a enterprise payroll application. You have a 
> model package. You have model.Employee. Having to use model.Employee 
> throughout the application is noise. Everyone working on the application 
> knows that Employee means model.Employee. It is part of the language (dsl in 
> a way) for that application. 

Now suppose you have to write a application that
has to access payroll as well as employee performance
review, health insurance, expense reporting, connect
to 3rd parties for special discounts for various things,
etc. Each of these subsystems may have their own
definition of Employee (which may be stored in their
own databases). This list may grow over time and you
don't want to have to recompile and retest *existing*
packages by changing some central Employee type.

-- 
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] Package Stutter

2018-12-03 Thread Bakul Shah

On Dec 2, 2018, at 11:39 PM, robert engels  wrote:
> 
> what I’m really trying to convey is that “Fixed” is a top-level type, on 
> equal footing with ‘string’.

a) it is *not* on equal footing with the built in types of Go.
b) it can't be, as "Fixed" by itself not well defined. The
   Fixed type in your pkg assumes a specific scale factor,
   which may not be right for everyone. In general you'd have
   to allow specifying the fractional parr. For example, PL/I
   provides
FIXED BINARY(number of bits, fractional bits) &
FIXED DECIMAL(number of digits, fractional digits)
   for this purpose. The Fixed type in your pkg is *roughly*
   equivalent to FIXED DECIMAL(19,7). Fixed types have a
   very limited use so it wouldn't make sense to add them to
   a general purpose language such as Go. 

On dot imports. It is a bad idea. Everyone with far more
experience than you or I have said the same thing and given
their reasons. I suspect you will come around their PoV over
time!

-- 
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] Package Stutter

2018-12-01 Thread Bakul Shah

I would've probably chosen context.State or context.Type;
but to be frank "Context" always seemed a bit too generic
to me. Looking at its definition it seems like something
to carry a bunch of random stuff. Sort of like a knapsack!

Naming is not easy. As usual Dijkstra has something
interesting to say about this topic!
https://www.cs.utexas.edu/users/EWD/ewd09xx/EWD958.PDF

> On Dec 1, 2018, at 6:51 PM, Sameer Ajmani  wrote:
> 
> For what it's worth, we considered various ways to shorten context.Context 
> before releasing it as open source. The obvious choice would be context.C, 
> but I was concerned this would encourage people to name their context 
> variables c, which conflicts with the common short name for channel 
> variables. Since we typically use the short name ctx, we also considered the 
> type name context.Ctx, but this seemed too arbitrary. We went with 
> context.Context because it's clear and doesn't introduce any unnecessary 
> confusion.
> S
> On Sat, Dec 1, 2018 at 1:25 PM Robert Engels  wrote:
> I agree. You need to understand the expected usage patterns (and possibly 
> other external and internal constraints) before you can claim that any design 
> “needs change”. 
> 
> On Dec 1, 2018, at 12:18 PM, Bakul Shah  wrote:
> 
>> Reducing stutter.Stutter is a good thing. But coming up with meaningful
>> names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
>> hard (but ultimately rewarding as it forces you to think more clearly).
>> And languages and practices evolve as people gain more experience
>> so early practices should not be seen as a model for newer code.
>> 
>> Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
>> where the fixed point lies for this type. In my case I used currency.Type for
>> its main type, not currency.Currency. The "fixed point" may in fact depend
>> on a specific currency.
>> 
>> Bottom line: think of "reduce stutter" as a *best practice* but not a *rule*!
>> 
>>> On Dec 1, 2018, at 9:53 AM, Robert Engels  wrote:
>>> 
>>> That was my point. The earliest practitioners and language designers used 
>>> the construct extensively but now others claim it is not the way. I find it 
>>> hard to believe that in testing the original Go design the creators didn’t 
>>> think about this - which means they decided it was fine. So why the change?
>>> 
>>> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  wrote:
>>> 
>>>> In the cases of time and context, the stutters appear in a primary type 
>>>> that is important to the package, but rarely appears directly in normal 
>>>> API usage.
>>>>   E.g., time.Now(), context.Background().  
>>>>   Stutter is to be avoided. The package name can provide context. But 
>>>> stutter is preferred to, e.g. time.Type, where one package largely 
>>>> operates on one type
>>>>   I doubt there would be a peer reviewed paper on something which is 
>>>> basically just an opinion held by the language's earliest practitioners. 
>>>> It doesn't mean the idea does not have merit though.
>>>> 
>>>> On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:
>>>> In another thread, it has been brought up that things like time.Time are 
>>>> no good. But this format is pervasive. Even newer packages like 
>>>> context.Context.
>>>> 
>>>> It seems to have been this way for a long time. 
>>>> 
>>>> It there some reasoned paper on why this is now so frowned upon?
>>>> 
>>>> -- 
>>>> 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.
>> 
> 
> -- 
> 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] Package Stutter

2018-12-01 Thread Bakul Shah

Reducing stutter.Stutter is a good thing. But coming up with meaningful
names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
hard (but ultimately rewarding as it forces you to think more clearly).
And languages and practices evolve as people gain more experience
so early practices should not be seen as a model for newer code.

Nigel Tao mentioned fixed.Int26_6, which is much more useful as it shows
where the fixed point lies for this type. In my case I used currency.Type for
its main type, not currency.Currency. The "fixed point" may in fact depend
on a specific currency.

Bottom line: think of "reduce stutter" as a *best practice* but not a *rule*!

> On Dec 1, 2018, at 9:53 AM, Robert Engels  wrote:
> 
> That was my point. The earliest practitioners and language designers used the 
> construct extensively but now others claim it is not the way. I find it hard 
> to believe that in testing the original Go design the creators didn’t think 
> about this - which means they decided it was fine. So why the change?
> 
> On Dec 1, 2018, at 11:01 AM, Tristan Colgate  > wrote:
> 
>> In the cases of time and context, the stutters appear in a primary type that 
>> is important to the package, but rarely appears directly in normal API usage.
>>   E.g., time.Now(), context.Background().  
>>   Stutter is to be avoided. The package name can provide context. But 
>> stutter is preferred to, e.g. time.Type, where one package largely operates 
>> on one type
>>   I doubt there would be a peer reviewed paper on something which is 
>> basically just an opinion held by the language's earliest practitioners. It 
>> doesn't mean the idea does not have merit though.
>> 
>> On Sat, 1 Dec 2018, 14:19 Robert Engels, > > wrote:
>> In another thread, it has been brought up that things like time.Time are no 
>> good. But this format is pervasive. Even newer packages like context.Context.
>> 
>> It seems to have been this way for a long time. 
>> 
>> It there some reasoned paper on why this is now so frowned upon?
>> 
>> -- 
>> 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 
> .

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

1 2 >

1 - 100 of 187 matches

Mail list logo