[go-nuts] Re: Fully-qualified import paths and Pull Requests

[Dave Cheney]

This discussion could get confusing if we're not clear about our terms. Could 
you please describe what the terms cloned and forked mean to you.

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

[go-nuts] Re: Fully-qualified import paths and Pull Requests

[st ov]

Should the source repo be cloned or forked first? Or does it not matter?
I was thinking there could be an issue with someone pushing a change after 
its cloned but before its forked.



On Tuesday, May 2, 2017 at 11:55:41 PM UTC-7, Nathan Kerr wrote:
>
> http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives some 
> good pointers on how to do this.

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

Re: [go-nuts] why iota can't be assigned to variables?

[T L]

On Thursday, May 4, 2017 at 1:21:52 AM UTC+8, Axel Wagner wrote:
>
> On Wed, May 3, 2017 at 7:04 PM, T L  
> wrote:
>
>>
>>
>> On Thursday, May 4, 2017 at 12:46:47 AM UTC+8, Axel Wagner wrote:
>>>
>>> but
>>> const (
>>> a = iota
>>> b
>>> s string
>>> d
>>> )
>>> is not a valid declaration. You can't say "the rule is the same for 
>>> constants".
>>>
>>
>> For the same rule, I mean just copying the corresponding part from last 
>> line.
>> Yes, declared constant must be assigned. This is an unrelated rule for 
>> this topic.
>>
>
> No, it is not an unrelated rule. Because it means that "just like for 
> consts" isn't an argument. You need, at the very least, answer the valid 
> question ("what happens with that var-declaration and why?") raised about 
> your proposal. Or better yet, realize that var and const declarations 
> behave very differently and thus "consistency" isn't an argument to add 
> something otherwise useless.
>
>
ok, I admit the rule difference between variable and constant declaration 
does matter:

var (
a int = iota
b// should autocomplete
c int// but this? "c int" is already legal.
)

 

>
>>  
>>
>>>
>>> Again: const-declarations and variable declarations are very different. 
>>> You can not argue "it's the same"; it's not.
>>>
>>> On Wed, May 3, 2017 at 6:28 PM, T L  wrote:
>>>


 On Thursday, May 4, 2017 at 12:17:13 AM UTC+8, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 6:00 PM T L  wrote:
>
> > Just like what expected for constants.
>
> For constants it's expected to reuse the last iota expression when 
> absent. Do you propose that
>
> var (
> a = iota
> b
> )
>
> will become valid and initialize a to 0 and b to 1?
>
> If so, is it valid and what shall happen when one writes
>
> var (
> a = iota
> b
> s string
> d
> )
>
> ?
>

 The rule is same for constants: d is also string, as s.

  

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

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

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

Re: [go-nuts] Interaction between Test and Benchmark functions?

[Peter Fröhlich]

I can now confirm that in Go 1.8.1 this is *much* less of a problem
than in Go 1.7.5 although the details of what's happening there are
still quite unclear to me. Here's what I get now, comparing the
benchmarks with all test cases included and with some test cases
commented out:

-CUT-
$ benchstat bench.txt bench-commented.txt
name   old time/opnew time/opdelta
PushFrontQueue-2 82.8µs ± 1%82.7µs ± 1%~ (p=0.832 n=16+19)
PushFrontList-2   162µs ± 1% 161µs ± 1%  -0.48%  (p=0.003 n=18+19)
PushBackQueue-2  83.4µs ± 1%83.3µs ± 1%~ (p=0.756 n=16+19)
PushBackList-2158µs ± 3% 156µs ± 1%  -1.02%  (p=0.024 n=20+19)
PushBackChannel-2 110µs ± 2% 110µs ± 2%~ (p=0.341 n=20+20)
RandomQueue-2 161µs ± 2% 158µs ± 4%  -2.28%  (p=0.000 n=20+20)
RandomList-2  281µs ± 4% 279µs ± 1%~ (p=0.223 n=19+19)
GrowShrinkQueue-2 110µs ± 1% 111µs ± 2%  +1.41%  (p=0.000 n=19+18)
GrowShrinkList-2  170µs ± 5% 168µs ± 1%  -1.19%  (p=0.017 n=20+19)
-CUT-

There *is* still a difference, but at least now it's no longer 10
microseconds like it was in 1.7.5. Whoever fixed this on the way to
1.8: My thanks! Now if you'd just also fix the memory benchmark
scores... :-)

On Tue, Apr 25, 2017 at 9:19 PM, Peter Fröhlich
 wrote:
> Thank you David and Caleb, those were helpful suggestions, especially
> benchstat! Check out my conclusions though... :-/ I am running these
> four:
>
> $ go test -bench=. -count=10 >normal.txt
> $ go test -run=XXX -bench=. -count=10 >filter.txt
> $ go test -bench=. -count=10 >comment.txt
> $ go test -run=XXX -bench=. -count=10 >comment_filter.txt
>
> As you might guess, the last two are when I manually comment out the
> body of the test function. Here's the result:
>
> $ benchstat normal.txt filter.txt
> nameold time/op  new time/op  delta
> PushBack-2   380µs ± 0%   380µs ± 1%   ~ (p=0.447 n=10+9)
>
> So filtering the test case out with -run seems to make no difference.
>
> $ benchstat normal.txt comment.txt
> nameold time/op  new time/op  delta
> PushBack-2   380µs ± 0%   355µs ± 1%  -6.45%  (p=0.000 n=10+9)
>
> So commenting it out (the body!) leads to what I observed earlier,
> just more reliably now thanks to running it 10 times.
>
> $ benchstat comment.txt  comment_filter.txt
> nameold time/op  new time/op  delta
> PushBack-2   355µs ± 1%   357µs ± 1%   ~ (p=0.278 n=9+10)
>
> So applying the filter on top of commenting things out (just sanity
> checking!) changes nothing again.
>
> Since Caleb said he cannot detect a difference on his machine with his
> version of Go, I am wondering if what I am seeing is just a weird
> artifact of my ancient machine and old Go release. I'll try upgrading
> soon. Also I'll try to see what I get on different machines I have
> access too.
>
> Thanks again!
>
> On Tue, Apr 25, 2017 at 8:03 PM, Caleb Spare  wrote:
>> Hi Peter,
>>
>> Running your code locally (Go 1.8.1 / linux / amd64), I don't get a
>> statistically significant difference between the two. The benchmark
>> does generate a ton of garbage so the GC causes the benchmark runs to
>> have a pretty decent variance.
>>
>> To check this kind of thing, you'll want to run the benchmarks many
>> times and then compare the distributions using a tool like benchstat:
>> https://godoc.org/golang.org/x/perf/cmd/benchstat
>>
>> For example:
>>
>> go test -bench . -count 10 | tee old.txt
>> # make changes
>> go test -bench . -count 10 | tee new.txt
>> benchstat old.txt new.txt
>>
>> When I've seen effects like this before, one explanation I've seen is
>> that the code alignment can change performance characteristics (this
>> only applies to the tightest of loops, IIRC). Too lazy to look up
>> references right now, but I've definitely seen this discussed on this
>> mailing list as well as various issues.
>>
>> -Caleb
>>
>> On Tue, Apr 25, 2017 at 4:09 PM, Peter Fröhlich
>>  wrote:
>>> Hi all,
>>>
>>> Sorry if this is an FAQ, but then my Google-foo has failed me. :-/
>>>
>>> It seems to me that the test functions in a bla_test.go file influence
>>> the benchmark functions in the same file. In the snippet below, if I
>>> comment out the body of the test function, I get better benchmark
>>> numbers than when I leave it in. Suspecting some GC "leftovers" from
>>> the test, I've tried adding "runtime.GC(); b.ResetTimer()" to the
>>> benchmark but that doesn't actually help.
>>>
>>> Before I dig through the source for Go's testing module itself, I
>>> wanted to see if this is a well-known issue, maybe with a well-known
>>> workaround?
>>>
>>> Best,
>>> Peter
>>>
>>> -CUT-
>>> $ go version
>>> go version go1.7.5 linux/amd64
>>> $ cat bla_test.go
>>> package main
>>>
>>> import "testing"
>>> import "container/list"
>>> import "runtime"
>>>
>>> const size = 2270
>>>
>>> func 

[go-nuts] Re: RTP/RSTP and OVNIF?

[howardcshaw]

https://golanglibs.com/top?q=rtsp lists several for rstp. I have not used 
any, so I cannot recommend one over another. As for ONVIF, I don't know of 
any implementations, but it is just a SOAP api, so generic SOAP programming 
should be enough to interact with it, I believe. Here is a SOAP/WSDL 
library for golang: https://github.com/justwatchcom/goat

Howard

-- 
You received this message because you are subscribed to the Google 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] GC problem

[peterGo]

Serhat Şevki Dinçer,

FYI

Swapfiles by default in Ubuntu
http://blog.surgut.co.uk/2016/12/swapfiles-by-default-in-ubuntu.html

"By default, in Ubuntu, we usually create a swap partition."

"Starting from 17.04 Zesty Zapus release, instead of creating swap 
partitions, swapfiles will be used by default for non-lvm based 
installations."

Peter

On Wednesday, May 3, 2017 at 2:19:25 PM UTC-4, peterGo wrote:
>
> Serhat Şevki Dinçer,
>
> "why cant peterGo reproduce the crash?"
>
> Because I have swap space. 
>
> $ go build ssd.go
> $ cat /proc/swaps
> FilenameType SizeUsedPriority
> /dev/sda5   partition79994840   -1
> $ ./ssd
> 8
> 9
> $ cat /proc/swaps
> FilenameType SizeUsedPriority
> /dev/sda5   partition7999484 1723860-1
> $ 
>
> Peter
>
> On Wednesday, May 3, 2017 at 11:24:40 AM UTC-4, Serhat Şevki Dinçer wrote:
>>
>> Ok if GOGC is the trigger point, then out-of-memory error should be 
>> consistent on all Ubuntu 64-bit 4gb systems, right?
>> If so, why cant peterGo reproduce the crash?
>>
>> 2 May 2017 16:08 tarihinde "Юрий Соколов"  yazdı:
>>
>>> There is nowhere told that GOGC defines border that could not be 
>>> reached. GOGC defines proportion that triggers GC, ie GC is triggered AFTER 
>>> GOGC proportion crossed, not before.
>>>
>>> In fact, if you allocates by small portions, then GC tries to predict 
>>> when you will reach this border, and tries to start earlier. But it doesn't 
>>> stop your program if you run faster and cross this border, cause current 
>>> Golang GC us concurrent and tries to minimize GC pause. How could it 
>>> minimize GC pause if it ought to stop whole your program to not cross GOGC 
>>> proportion?
>>>
>>> And you partially right: GC of old Go's versions may stop program before 
>>> GOGC proportion crossed. So, if you try Go 1.0 most likely your programm 
>>> will run.
>>>
>>> But new behaviour is much better.
>>>
>>> The point: you should know your instrument and environment. No one GC 
>>> enabled runtime will be happy if you allocate huge arrays (perl/python/php 
>>> are exceptions, cause they use reference counting). If you ought to 
>>> allocate huge arrays in GC runtime, use off-heap allocation (Java men learn 
>>> that hard way).
>>>
>>> For example, you may use mmap to allocate huge array.
>>>
>>> Or, I'll repeat my self, use datastructure without huge continuous 
>>> allocation (ie slice of slices for your example). Then GC will have a 
>>> chance to trigger ealier and free some memory before it exhausted.
>>>
>>> 2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" <
>>> jfcg...@gmail.com> написал:
>>>
>>> The allocation request (make) is made to the runtime which covers GC, 
>>> right? GC percent is also set to 10%.
>>> After 1st call returns, my app has about 2gb ram allocated. When 2nd 
>>> call requests allocation, runtime cannot:
>>> - first allocate another 2gb
>>> - free the 1st buffer later
>>> due to the definition of the GOGC (GC percent).
>>> I think this is a GC bug.
>>>
>>> 2 May 2017 07:09 tarihinde "Sokolov Yura"  yazdı:
>>>
>>> GC is triggered *after* allocation than crosses boundary. So your second 
 allocation is actually tries to complete before first allocation freed. 
 And 
 Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause 
 overcommit is not enabled by default.

 Use C/C++, or buy more memory, or change your datastructure from slice 
 to slice of slice and allocate second dimension lazely, or call 
 runtime.GC() explicitely between calls to f() (it will block until GC 
 finishes).

 --
 You received this message because you are subscribed to a topic in the 
 Google Groups "golang-nuts" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/golang-nuts/HrZpsyfb3i0/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>

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

Re: [go-nuts] GC problem

[peterGo]

Serhat Şevki Dinçer,

"why cant peterGo reproduce the crash?"

Because I have swap space. 

$ go build ssd.go
$ cat /proc/swaps
FilenameType SizeUsedPriority
/dev/sda5   partition79994840   -1
$ ./ssd
8
9
$ cat /proc/swaps
FilenameType SizeUsedPriority
/dev/sda5   partition7999484 1723860-1
$ 

Peter

On Wednesday, May 3, 2017 at 11:24:40 AM UTC-4, Serhat Şevki Dinçer wrote:
>
> Ok if GOGC is the trigger point, then out-of-memory error should be 
> consistent on all Ubuntu 64-bit 4gb systems, right?
> If so, why cant peterGo reproduce the crash?
>
> 2 May 2017 16:08 tarihinde "Юрий Соколов"  > yazdı:
>
>> There is nowhere told that GOGC defines border that could not be reached. 
>> GOGC defines proportion that triggers GC, ie GC is triggered AFTER GOGC 
>> proportion crossed, not before.
>>
>> In fact, if you allocates by small portions, then GC tries to predict 
>> when you will reach this border, and tries to start earlier. But it doesn't 
>> stop your program if you run faster and cross this border, cause current 
>> Golang GC us concurrent and tries to minimize GC pause. How could it 
>> minimize GC pause if it ought to stop whole your program to not cross GOGC 
>> proportion?
>>
>> And you partially right: GC of old Go's versions may stop program before 
>> GOGC proportion crossed. So, if you try Go 1.0 most likely your programm 
>> will run.
>>
>> But new behaviour is much better.
>>
>> The point: you should know your instrument and environment. No one GC 
>> enabled runtime will be happy if you allocate huge arrays (perl/python/php 
>> are exceptions, cause they use reference counting). If you ought to 
>> allocate huge arrays in GC runtime, use off-heap allocation (Java men learn 
>> that hard way).
>>
>> For example, you may use mmap to allocate huge array.
>>
>> Or, I'll repeat my self, use datastructure without huge continuous 
>> allocation (ie slice of slices for your example). Then GC will have a 
>> chance to trigger ealier and free some memory before it exhausted.
>>
>> 2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" <
>> jfcg...@gmail.com > написал:
>>
>> The allocation request (make) is made to the runtime which covers GC, 
>> right? GC percent is also set to 10%.
>> After 1st call returns, my app has about 2gb ram allocated. When 2nd call 
>> requests allocation, runtime cannot:
>> - first allocate another 2gb
>> - free the 1st buffer later
>> due to the definition of the GOGC (GC percent).
>> I think this is a GC bug.
>>
>> 2 May 2017 07:09 tarihinde "Sokolov Yura" > > yazdı:
>>
>> GC is triggered *after* allocation than crosses boundary. So your second 
>>> allocation is actually tries to complete before first allocation freed. And 
>>> Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause 
>>> overcommit is not enabled by default.
>>>
>>> Use C/C++, or buy more memory, or change your datastructure from slice 
>>> to slice of slice and allocate second dimension lazely, or call 
>>> runtime.GC() explicitely between calls to f() (it will block until GC 
>>> finishes).
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/golang-nuts/HrZpsyfb3i0/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> golang-nuts...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [go-nuts] why iota can't be assigned to variables?

['Axel Wagner' via golang-nuts]

On Wed, May 3, 2017 at 7:04 PM, T L  wrote:

>
>
> On Thursday, May 4, 2017 at 12:46:47 AM UTC+8, Axel Wagner wrote:
>>
>> but
>> const (
>> a = iota
>> b
>> s string
>> d
>> )
>> is not a valid declaration. You can't say "the rule is the same for
>> constants".
>>
>
> For the same rule, I mean just copying the corresponding part from last
> line.
> Yes, declared constant must be assigned. This is an unrelated rule for
> this topic.
>

No, it is not an unrelated rule. Because it means that "just like for
consts" isn't an argument. You need, at the very least, answer the valid
question ("what happens with that var-declaration and why?") raised about
your proposal. Or better yet, realize that var and const declarations
behave very differently and thus "consistency" isn't an argument to add
something otherwise useless.


>
>
>>
>> Again: const-declarations and variable declarations are very different.
>> You can not argue "it's the same"; it's not.
>>
>> On Wed, May 3, 2017 at 6:28 PM, T L  wrote:
>>
>>>
>>>
>>> On Thursday, May 4, 2017 at 12:17:13 AM UTC+8, Jan Mercl wrote:

 On Wed, May 3, 2017 at 6:00 PM T L  wrote:

 > Just like what expected for constants.

 For constants it's expected to reuse the last iota expression when
 absent. Do you propose that

 var (
 a = iota
 b
 )

 will become valid and initialize a to 0 and b to 1?

 If so, is it valid and what shall happen when one writes

 var (
 a = iota
 b
 s string
 d
 )

 ?

>>>
>>> The rule is same for constants: d is also string, as s.
>>>
>>>
>>>

 If it's not valid, why?


 --

 -j

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> 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] Re: Is there a way to fee a memory object on demand?

[Piotr Narewski]

:-)

I see what you mean, but unfortunately I cannot put it back just yet.. ;-)

But the whole idea is a good thing to explore.
Most of the data chunks I use have certain sizes - perhaps I can sort them 
into some groups hold by separate pools.
I'm going to look int this kind of solution.

Thank you very much, Jan!

On Wednesday, May 3, 2017 at 7:01:34 PM UTC+2, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 6:50 PM Piotr Narewski  > wrote:
>
> > Perhaps that is the reason; when I need 515 bytes, it actually allocates 
> 1024
> > This might be when I'm loosing the mem.
>
> Not if you Put() it back after use ;-)
>
> It's of course also possible to make the allocation granularity finer if 
> necessary (and/or Fibonacci-ish).
>
> -- 
>
> -j
>

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

Re: [go-nuts] why iota can't be assigned to variables?

[T L]

On Thursday, May 4, 2017 at 12:46:47 AM UTC+8, Axel Wagner wrote:
>
> but
> const (
> a = iota
> b
> s string
> d
> )
> is not a valid declaration. You can't say "the rule is the same for 
> constants".
>

For the same rule, I mean just copying the corresponding part from last 
line.
Yes, declared constant must be assigned. This is an unrelated rule for this 
topic.

 

>
> Again: const-declarations and variable declarations are very different. 
> You can not argue "it's the same"; it's not.
>
> On Wed, May 3, 2017 at 6:28 PM, T L  
> wrote:
>
>>
>>
>> On Thursday, May 4, 2017 at 12:17:13 AM UTC+8, Jan Mercl wrote:
>>>
>>> On Wed, May 3, 2017 at 6:00 PM T L  wrote:
>>>
>>> > Just like what expected for constants.
>>>
>>> For constants it's expected to reuse the last iota expression when 
>>> absent. Do you propose that
>>>
>>> var (
>>> a = iota
>>> b
>>> )
>>>
>>> will become valid and initialize a to 0 and b to 1?
>>>
>>> If so, is it valid and what shall happen when one writes
>>>
>>> var (
>>> a = iota
>>> b
>>> s string
>>> d
>>> )
>>>
>>> ?
>>>
>>
>> The rule is same for constants: d is also string, as s.
>>
>>  
>>
>>>
>>> If it's not valid, why?
>>>
>>>
>>> -- 
>>>
>>> -j
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> 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: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 6:50 PM Piotr Narewski  wrote:

> Perhaps that is the reason; when I need 515 bytes, it actually allocates
1024
> This might be when I'm loosing the mem.

Not if you Put() it back after use ;-)

It's of course also possible to make the allocation granularity finer if
necessary (and/or Fibonacci-ish).

-- 

-j

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

Re: [go-nuts] GC problem

[Jesper Louis Andersen]

TL;DR: It depends on the kernels configuration and the amount of swap space.

Longer explanation:

When a malloc() is granted by the kernel, it allocates the space virtually.
It doesn't yet assign physical DRAM space to the allocation because it
speculates that you are not going to use all the space up front, and thus
allocating it a bit at a time is more efficient. Whenever you access a new
portion of the virtual space, a kernel trap is triggered and the kernel
allocates physical space for the given portion and resumes the program.

Linux kernels can overcommit memory. This means the kernel can hand out
memory it doesn't have guaranteed available. It does so in the hope that
when you actually need the space, some other program has completed and then
it can use that space. Another way to get more memory is by using swap
space as additional memory, albeit at a slower pace.

What likely happens on peterGo's machine is the following: The extra 2.2gb
memory is allocated virtually, but as you walk through that memory space
getting kernel trapped all the time, the garbage collection completes and
advices the kernel there is a large space of memory which isn't needed
anymore. So when it finally comes along and needs space because it is about
to run out, a newly freed up portion is available. The alternative
hypothesis is that peterGo has ample amounts of swap space available and
uses this partially.

Ubuntu doesn't overcommit by default, as already stated in this thread.
Solaris/Illumos can't overcommit memory at all for instance.

Note that the scenario is likely to be brittle: depending on timing, your
program may either run much slower than envisioned, or not even run at all
when you are close to the boundary of available memory in a machine. The
kernel will also have to find the space somewhere, usually by erasing the
disk cache to make up for the demand of memory pressure.


On Wed, May 3, 2017 at 5:23 PM Serhat Sevki Dincer 
wrote:

> Ok if GOGC is the trigger point, then out-of-memory error should be
> consistent on all Ubuntu 64-bit 4gb systems, right?
> If so, why cant peterGo reproduce the crash?
>
> 2 May 2017 16:08 tarihinde "Юрий Соколов"  yazdı:
>
> There is nowhere told that GOGC defines border that could not be reached.
>> GOGC defines proportion that triggers GC, ie GC is triggered AFTER GOGC
>> proportion crossed, not before.
>>
>> In fact, if you allocates by small portions, then GC tries to predict
>> when you will reach this border, and tries to start earlier. But it doesn't
>> stop your program if you run faster and cross this border, cause current
>> Golang GC us concurrent and tries to minimize GC pause. How could it
>> minimize GC pause if it ought to stop whole your program to not cross GOGC
>> proportion?
>>
>> And you partially right: GC of old Go's versions may stop program before
>> GOGC proportion crossed. So, if you try Go 1.0 most likely your programm
>> will run.
>>
>> But new behaviour is much better.
>>
>> The point: you should know your instrument and environment. No one GC
>> enabled runtime will be happy if you allocate huge arrays (perl/python/php
>> are exceptions, cause they use reference counting). If you ought to
>> allocate huge arrays in GC runtime, use off-heap allocation (Java men learn
>> that hard way).
>>
>> For example, you may use mmap to allocate huge array.
>>
>> Or, I'll repeat my self, use datastructure without huge continuous
>> allocation (ie slice of slices for your example). Then GC will have a
>> chance to trigger ealier and free some memory before it exhausted.
>>
>> 2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" <
>> jfcga...@gmail.com> написал:
>>
>> The allocation request (make) is made to the runtime which covers GC,
>> right? GC percent is also set to 10%.
>> After 1st call returns, my app has about 2gb ram allocated. When 2nd call
>> requests allocation, runtime cannot:
>> - first allocate another 2gb
>> - free the 1st buffer later
>> due to the definition of the GOGC (GC percent).
>> I think this is a GC bug.
>>
>> 2 May 2017 07:09 tarihinde "Sokolov Yura"  yazdı:
>>
>> GC is triggered *after* allocation than crosses boundary. So your second
>>> allocation is actually tries to complete before first allocation freed. And
>>> Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause
>>> overcommit is not enabled by default.
>>>
>>> Use C/C++, or buy more memory, or change your datastructure from slice
>>> to slice of slice and allocate second dimension lazely, or call
>>> runtime.GC() explicitely between calls to f() (it will block until GC
>>> finishes).
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/golang-nuts/HrZpsyfb3i0/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email 

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 6:39 PM Piotr Narewski  wrote:

> I am supposed to allocate the slice with "slice.Bytes.Get(515).(*[]byte)"
not "make([]byte, 515)"

Yes. Even better is

p := slice.Bytes.Get(n)
b := *p
... use b as usual, it's already a []byte.
slice.Bytes.Put(p)

This way the slice header will not be allocated again (out of the pool).



-- 

-j

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Piotr Narewski]

Yes.
Perhaps that is the reason; when I need 515 bytes, it actually allocates 
1024
This might be when I'm loosing the mem.

On Wednesday, May 3, 2017 at 6:47:53 PM UTC+2, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 6:28 PM Piotr Narewski  > wrote:
>
> > I've checked it and I think there is something wrong with this lib.
>
> I haven't checked thoroughly, but it seems to be working as intended. If 
> you Put(515) the correct bin to use is the one for sizes 257-512. If you 
> Get(515), the correct bin to use is the [next] one for sizes 513-1024.
>
> Try it differently:
>
> dat := slice.Bytes.Get(515)
> println(dat)
> slice.Bytes.Put(dat)
> dat = slice.Bytes.Get(515)
> println(dat)
>
> Now the first Get(515) will create (the list.Pool is empty) a new 
> cap(1024) slice. The subsequent Put returns the slice to the correct bin so 
> the last println should show the same address.
>
> -- 
>
> -j
>

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

[go-nuts] Re: [ANN] the busy man: init repo quickly

[mhhcbon]

hi,

I HEARD YOU : )

It is installing the software for you JIT, 
see https://github.com/mh-cbon/the-busy-man/blob/master/emd/tbm.go#L36 ;)

And yes, unfortunately, it does not *yet* complete the whole setup like
https://github.com/mh-cbon/go-github-release

And yes it uses HEAD everywhere, 
its not so great, waiting for dep to jump in to take decision.

In regards to apt/dnf lately i got caught by them pretty often lately,
because, either i did not understand, either they are too weak,
so i want to see dep in action to decide.

Lastly, this tool is quiet specific to developers, 
so far given its visibility mostly gophers, 
so go get seems reasonable to me.

But yes i agree with you, just not enough arms and brains 
Maybe someday we ll be able to type in like
 in the animé ghost in the shell (btw the movie is awesome)
https://www.youtube.com/watch?v=KlJ8eTuFe9U


On Wednesday, May 3, 2017 at 6:23:48 PM UTC+2, Tong Sun wrote:
>
> Hi, 
>
> That'd be very useful, but only under one condition IMO, is that people 
> can do 
>
> apt get install the-busy-man
>
> and get all the dependent tools of the-busy-man installed *automatically*. 
> Otherwise, if people have to figure out the dependencies *themselves*, 
> and install them *one by one* themselves, I'd see only few people willing 
> to do that, i.e., terrible adaption rate. 
>
>
> On Wednesday, May 3, 2017 at 6:52:32 AM UTC-4, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> made that because i was super lazy...
>>
>> https://github.com/mh-cbon/the-busy-man
>>
>> So now i can do,
>>
>> 1/ add an alias of my preferred repo init,
>>
>> $ cat <> ~/.bashrcalias tbm="the-busy-man git:init license:mit 
>> emd:mh-cbon/emd golang gump:mh-cbon/gump git:commit changelog 
>> git:commit+amend"EOTsource ~/.bashrc
>>
>> 2/ run `tbm` into a directory to get a package ready to code
>>
>> For plugins such a `license`, `emd` ect,
>> they rely on external go bin, 
>> so the program will install them via go get,
>> BUT, take care its HEAD everywhere (not so great.)
>>
>> its not a bultin pipe of init 
>> because everyone is doing something
>> a bit different of his neighbor
>> so i suggest you pr  plugins for your needs.
>>
>> A basic miss is the Makefile, because i m not Makefile user,
>> the idea would be to add a new plugin named `make`
>> and let it receive an intent such `cznic/sqlite`
>> and the program would init the makefile using the file existing in the repo
>> https://github.com/cznic/sqlite/blob/master/Makefile
>>
>> Its basically what i shown in my alias with plugins like emd/gump.
>>
>> hth
>>
>>

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 6:28 PM Piotr Narewski  wrote:

> I've checked it and I think there is something wrong with this lib.

I haven't checked thoroughly, but it seems to be working as intended. If
you Put(515) the correct bin to use is the one for sizes 257-512. If you
Get(515), the correct bin to use is the [next] one for sizes 513-1024.

Try it differently:

dat := slice.Bytes.Get(515)
println(dat)
slice.Bytes.Put(dat)
dat = slice.Bytes.Get(515)
println(dat)

Now the first Get(515) will create (the list.Pool is empty) a new cap(1024)
slice. The subsequent Put returns the slice to the correct bin so the last
println should show the same address.

-- 

-j

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

Re: [go-nuts] why iota can't be assigned to variables?

['Axel Wagner' via golang-nuts]

but
const (
a = iota
b
s string
d
)
is not a valid declaration. You can't say "the rule is the same for
constants".

Again: const-declarations and variable declarations are very different. You
can not argue "it's the same"; it's not.

On Wed, May 3, 2017 at 6:28 PM, T L  wrote:

>
>
> On Thursday, May 4, 2017 at 12:17:13 AM UTC+8, Jan Mercl wrote:
>>
>> On Wed, May 3, 2017 at 6:00 PM T L  wrote:
>>
>> > Just like what expected for constants.
>>
>> For constants it's expected to reuse the last iota expression when
>> absent. Do you propose that
>>
>> var (
>> a = iota
>> b
>> )
>>
>> will become valid and initialize a to 0 and b to 1?
>>
>> If so, is it valid and what shall happen when one writes
>>
>> var (
>> a = iota
>> b
>> s string
>> d
>> )
>>
>> ?
>>
>
> The rule is same for constants: d is also string, as s.
>
>
>
>>
>> If it's not valid, why?
>>
>>
>> --
>>
>> -j
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Piotr Narewski]

No sorry - I think I did not do it right.
I am supposed to allocate the slice with "slice.Bytes.Get(515).(*[]byte)" 
not "make([]byte, 515)"

In which case I still don't know why it's eating up my mem... :)

On Wednesday, May 3, 2017 at 6:28:20 PM UTC+2, Piotr Narewski wrote:
>
> Thanks.
>
> I've checked it and I think there is something wrong with this lib.
>
> If I do:
> dat := make([]byte, 515)
> slice.Bytes.Put()
> println(dat)
>
> And then:
> p := slice.Bytes.Get(515).(*[]byte)
> println(*p)
>
> It returns me a different slice.
>
> To get the same slice, I need to go down from 515 to 512 bytes:
> p := slice.Bytes.Get(512).(*[]byte)
> println(*p)
>
> This is pretty much similar for any other length value: put 111 needs get 
> 64, put 1 needs 8192, etc.
> That's where I think it's eating up the mem. 
> It just won't reuse a buffer of the same size.
>
>
>
> On Wednesday, May 3, 2017 at 4:42:28 PM UTC+2, Jan Mercl wrote:
>>
>> On Wed, May 3, 2017 at 4:24 PM Piotr Narewski  wrote:
>>
>> > I've just tried it and unfortunately it doesn't seem to be better than 
>> the traditional approach.
>> >
>> > With the pool in place, it still user too much memory (unlike my 
>> solution with using a heap via glibc).
>>
>> Sorry to hear that. There are few things worth checking:
>>
>> - slice.Put must be called once the slice will be no more used.
>> - The program may not keep any references to the slice passed to 
>> slice.Put.
>> - If you use append on the slice returned from slice.Get() you will 
>> effectively stop using the pool as append can allocate a new backing array 
>> but not by calling slice.Get/CGet. IOW, in such cases it's also necessary 
>> to write one's own append ;-)
>>
>> The best way to figure out where the memory consumption is happening when 
>> using slice.Pool is to profile it, example:
>>
>> $ go test -run @ -bench . -memprofile mem.out -memprofilerate 1
>> $ go tool pprof -lines -web -alloc_space *.test mem.out
>>
>> -- 
>>
>> -j
>>
>

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Piotr Narewski]

Thanks.

I've checked it and I think there is something wrong with this lib.

If I do:
dat := make([]byte, 515)
slice.Bytes.Put()
println(dat)

And then:
p := slice.Bytes.Get(515).(*[]byte)
println(*p)

It returns me a different slice.

To get the same slice, I need to go down from 515 to 512 bytes:
p := slice.Bytes.Get(512).(*[]byte)
println(*p)

This is pretty much similar for any other length value: put 111 needs get 
64, put 1 needs 8192, etc.
That's where I think it's eating up the mem. 
It just won't reuse a buffer of the same size.



On Wednesday, May 3, 2017 at 4:42:28 PM UTC+2, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 4:24 PM Piotr Narewski  > wrote:
>
> > I've just tried it and unfortunately it doesn't seem to be better than 
> the traditional approach.
> >
> > With the pool in place, it still user too much memory (unlike my 
> solution with using a heap via glibc).
>
> Sorry to hear that. There are few things worth checking:
>
> - slice.Put must be called once the slice will be no more used.
> - The program may not keep any references to the slice passed to slice.Put.
> - If you use append on the slice returned from slice.Get() you will 
> effectively stop using the pool as append can allocate a new backing array 
> but not by calling slice.Get/CGet. IOW, in such cases it's also necessary 
> to write one's own append ;-)
>
> The best way to figure out where the memory consumption is happening when 
> using slice.Pool is to profile it, example:
>
> $ go test -run @ -bench . -memprofile mem.out -memprofilerate 1
> $ go tool pprof -lines -web -alloc_space *.test mem.out
>
> -- 
>
> -j
>

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

Re: [go-nuts] why iota can't be assigned to variables?

[T L]

On Thursday, May 4, 2017 at 12:17:13 AM UTC+8, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 6:00 PM T L  
> wrote:
>
> > Just like what expected for constants.
>
> For constants it's expected to reuse the last iota expression when absent. 
> Do you propose that
>
> var (
> a = iota
> b
> )
>
> will become valid and initialize a to 0 and b to 1?
>
> If so, is it valid and what shall happen when one writes
>
> var (
> a = iota
> b
> s string
> d
> )
>
> ?
>

The rule is same for constants: d is also string, as s.

 

>
> If it's not valid, why?
>
>
> -- 
>
> -j
>

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

[go-nuts] Re: [ANN] the busy man: init repo quickly

[Tong Sun]

Hi, 

That'd be very useful, but only under one condition IMO, is that people can 
do 

apt get install the-busy-man

and get all the dependent tools of the-busy-man installed *automatically*. 
Otherwise, if people have to figure out the dependencies *themselves*, and 
install them *one by one* themselves, I'd see only few people willing to do 
that, i.e., terrible adaption rate. 


On Wednesday, May 3, 2017 at 6:52:32 AM UTC-4, mhh...@gmail.com wrote:
>
> Hi,
>
> made that because i was super lazy...
>
> https://github.com/mh-cbon/the-busy-man
>
> So now i can do,
>
> 1/ add an alias of my preferred repo init,
>
> $ cat <> ~/.bashrcalias tbm="the-busy-man git:init license:mit 
> emd:mh-cbon/emd golang gump:mh-cbon/gump git:commit changelog 
> git:commit+amend"EOTsource ~/.bashrc
>
> 2/ run `tbm` into a directory to get a package ready to code
>
> For plugins such a `license`, `emd` ect,
> they rely on external go bin, 
> so the program will install them via go get,
> BUT, take care its HEAD everywhere (not so great.)
>
> its not a bultin pipe of init 
> because everyone is doing something
> a bit different of his neighbor
> so i suggest you pr  plugins for your needs.
>
> A basic miss is the Makefile, because i m not Makefile user,
> the idea would be to add a new plugin named `make`
> and let it receive an intent such `cznic/sqlite`
> and the program would init the makefile using the file existing in the repo
> https://github.com/cznic/sqlite/blob/master/Makefile
>
> Its basically what i shown in my alias with plugins like emd/gump.
>
> hth
>
>

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

Re: [go-nuts] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 6:00 PM T L  wrote:

> Just like what expected for constants.

For constants it's expected to reuse the last iota expression when absent.
Do you propose that

var (
a = iota
b
)

will become valid and initialize a to 0 and b to 1?

If so, is it valid and what shall happen when one writes

var (
a = iota
b
s string
d
)

?

If it's not valid, why?


-- 

-j

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

Re: [go-nuts] why iota can't be assigned to variables?

[T L]

On Wednesday, May 3, 2017 at 11:39:29 PM UTC+8, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 5:07 PM T L  
> wrote:
>
> > The complexity is the same as iota in constant declarations. 
>
> How can that be claimed when still nobody ever seen any specification of 
> what var foo = iota shall do at all? The space of possible semantics is 
> unbounded. The sane subspace seems to me to be of zero volume, but will you 
> please just explain what you expect from assigning iota to a variable?
>

Just like what expected for constants.

var (
  a = iota // a == 0
  b = iota // b == 1
)
 

>
> Don't suppose telepathy exists, thank you ;-)
>
> -- 
>
> -j
>

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

Re: [go-nuts] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 5:07 PM T L  wrote:

> The complexity is the same as iota in constant declarations.

How can that be claimed when still nobody ever seen any specification of
what var foo = iota shall do at all? The space of possible semantics is
unbounded. The sane subspace seems to me to be of zero volume, but will you
please just explain what you expect from assigning iota to a variable?

Don't suppose telepathy exists, thank you ;-)

-- 

-j

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

[go-nuts] Re: [ANN] listser/mutexer/channeler: generators.

[mhhcbon]

hi

> Can anyone else recommend any other generators that produce 
lists/iterators like this?

good Q.

> Is the resulting generated code safe to use from multiple go routines?

The slice itself nop, because, for that you want to use 

https://github.com/mh-cbon/channeler
or
https://github.com/mh-cbon/mutexer

You make a typed slice then you facade it with one of the syncer.

So yep, that example is not TS,
this was just for fun and demo

backend := NewTomates() // This is not TS, it d need an additional layer
backend.Push(Tomate{Name: "red"})
jsoner := NewJSONTomates(backend)
httper := NewHTTPTomates(jsoner)

// public views
http.HandleFunc("/", httper.At)

/*
curl -H "Accept: application/json" -H "Content-type: 
application/json" -X POST -d ' {"i":0}'  http://localhost:8080/
*/

log.Fatal(http.ListenAndServe(":8080", nil))


In the same manner if you have n collections in memory which needs TS,
that d be inappropriate to have n TS lists communicating with each other on 
the main routine,
that d create additional contentions,
you d better create a controller, that is totally TS, 
that access those slice without syncing.


On Wednesday, May 3, 2017 at 4:30:20 PM UTC+2, Ben Davies wrote:
>
> Is the resulting generated code safe to use from multiple go routines?
>
> On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> several generators i made to avoid some duplication.
>>
>> https://github.com/mh-cbon/lister
>>
>> Package lister is a generator to generate typed slice.
>>
>>
>> https://github.com/mh-cbon/channeler
>>
>> Package channeler is a cli generator to generate channeled version of a 
>> type.
>>
>> https://github.com/mh-cbon/mutexer
>>
>> Package mutexer is a cli generator to generate mutexed version of a type.
>>
>>
>> so basically, using below code you got hundreds of line generated for you,
>>
>>
>> in that example to make a mutexed []Tomate.
>>
>>
>> But as it s not too stupid, or tries too, it will be able to handle 
>>
>> pointer and basic types
>>
>> mutexed []*Tomate
>>
>> mutexed []string
>>
>> ect
>>
>>
>> It should also be able to lookup for a constructor of the src type 
>> (Tomate),
>>
>> and reproduce it into the dest type implementation.
>>
>>
>> There is both mutexer / channeler because both cases applies for reasons.
>>
>>
>> The lister is a convenient way to create typed slice.
>>
>>
>> package demo
>>
>> // Tomate is about red vegetables to make famous italian food.
>> type Tomate struct {
>> Name string
>> }
>>
>> // GetID return the ID of the Tomate.
>> func (t Tomate) GetID() string {
>> return t.Name
>> }
>>
>> //go:generate lister vegetables_gen.go Tomate:Tomates
>> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>>
>> hth
>>
>>

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

Re: [go-nuts] GC problem

[Serhat Sevki Dincer]

Ok if GOGC is the trigger point, then out-of-memory error should be
consistent on all Ubuntu 64-bit 4gb systems, right?
If so, why cant peterGo reproduce the crash?

2 May 2017 16:08 tarihinde "Юрий Соколов"  yazdı:

> There is nowhere told that GOGC defines border that could not be reached.
> GOGC defines proportion that triggers GC, ie GC is triggered AFTER GOGC
> proportion crossed, not before.
>
> In fact, if you allocates by small portions, then GC tries to predict when
> you will reach this border, and tries to start earlier. But it doesn't stop
> your program if you run faster and cross this border, cause current Golang
> GC us concurrent and tries to minimize GC pause. How could it minimize GC
> pause if it ought to stop whole your program to not cross GOGC proportion?
>
> And you partially right: GC of old Go's versions may stop program before
> GOGC proportion crossed. So, if you try Go 1.0 most likely your programm
> will run.
>
> But new behaviour is much better.
>
> The point: you should know your instrument and environment. No one GC
> enabled runtime will be happy if you allocate huge arrays (perl/python/php
> are exceptions, cause they use reference counting). If you ought to
> allocate huge arrays in GC runtime, use off-heap allocation (Java men learn
> that hard way).
>
> For example, you may use mmap to allocate huge array.
>
> Or, I'll repeat my self, use datastructure without huge continuous
> allocation (ie slice of slices for your example). Then GC will have a
> chance to trigger ealier and free some memory before it exhausted.
>
> 2 мая 2017 г. 1:59 PM пользователь "Serhat Sevki Dincer" <
> jfcga...@gmail.com> написал:
>
> The allocation request (make) is made to the runtime which covers GC,
> right? GC percent is also set to 10%.
> After 1st call returns, my app has about 2gb ram allocated. When 2nd call
> requests allocation, runtime cannot:
> - first allocate another 2gb
> - free the 1st buffer later
> due to the definition of the GOGC (GC percent).
> I think this is a GC bug.
>
> 2 May 2017 07:09 tarihinde "Sokolov Yura"  yazdı:
>
> GC is triggered *after* allocation than crosses boundary. So your second
>> allocation is actually tries to complete before first allocation freed. And
>> Ubuntu with 4GB memory doesn't allow to allocate 4GB memory cause
>> overcommit is not enabled by default.
>>
>> Use C/C++, or buy more memory, or change your datastructure from slice to
>> slice of slice and allocate second dimension lazely, or call runtime.GC()
>> explicitely between calls to f() (it will block until GC finishes).
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/golang-nuts/HrZpsyfb3i0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] Re: why iota can't be assigned to variables?

['Axel Wagner' via golang-nuts]

On Wed, May 3, 2017 at 4:59 PM, T L  wrote:
>
> On Wednesday, May 3, 2017 at 10:51:00 PM UTC+8, Axel Wagner wrote:
>>
>> I think it has been pointed out to you before, that go isn't a project
>> where "The request is not essential, but any harm of it?" is an acceptable
>> justification to add things.
>>
>> Or, to put it another way: Any addition has a harm, which is, that it's
>> complicating the language. You need to make your argument of why these
>> costs are justified.
>>
>
> isn't consistent a good argument? :)
>

In this case, not particularly. const and var declarations already are
incredibly different. And there is a much clearer use for iota for const
declarations, than for var.


>
>
>>
>> On Wed, May 3, 2017 at 4:45 PM, Tong Sun  wrote:
>>
>>> Oh, I misread the title.
>>>
>>> But iota only change while defining constance. Assigning them to
>>> variables will either get zero all the time, or Go need to define a very
>>> complicated theme how iota change while defining variables, very
>>> complicated I assume.
>>>
>>>
>>>
>>> On Wednesday, May 3, 2017 at 10:39:47 AM UTC-4, T L wrote:



 On Wednesday, May 3, 2017 at 10:27:47 PM UTC+8, Tong Sun wrote:
>
> I have no problem assigning iota to variables. Can you elaborate a bit
> pls?
>

 package main

 var a = iota // undefined: iota

 func main(){
 var a = iota // undefined: iota
 }


>
> On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:
>>
>> .
>>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google 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] why iota can't be assigned to variables?

[Ayan George]

On 05/03/2017 10:38 AM, T L wrote:
> 
> 
> On Wednesday, May 3, 2017 at 9:28:28 PM UTC+8, Jan Mercl wrote:
> 
> On Wed, May 3, 2017 at 3:19 PM T L  
> wrote:
> 
> Why would you want to assign iota to a variable? What value should 
> iota in such case have?
> 
> 
> The request is not essential, but any harm of it?
> 

Can you show an example (some preferably some mocked up Go code) of how
this can be useful?

-- 
You received this message because you are subscribed to the Google 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] why iota can't be assigned to variables?

[T L]

On Wednesday, May 3, 2017 at 10:53:42 PM UTC+8, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 4:38 PM T L  
> wrote:
>
> > The request is not essential, but any harm of it?
>
> How can anybody know that if nobody knows what it shall actually do and 
> what will be the impact on the complexity of the specification and 
> implementation?
>

The complexity is the same as iota in constant declarations. 


> -- 
>
> -j
>

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

Re: [go-nuts] Re: why iota can't be assigned to variables?

[T L]

On Wednesday, May 3, 2017 at 10:59:34 PM UTC+8, T L wrote:
>
>
>
> On Wednesday, May 3, 2017 at 10:51:00 PM UTC+8, Axel Wagner wrote:
>>
>> I think it has been pointed out to you before, that go isn't a project 
>> where "The request is not essential, but any harm of it?" is an acceptable 
>> justification to add things.
>>
>> Or, to put it another way: Any addition has a harm, which is, that it's 
>> complicating the language. You need to make your argument of why these 
>> costs are justified.
>>
>
> isn't consistent a good argument? :)
>
consistent => consistency

 

>  
>
>>
>> On Wed, May 3, 2017 at 4:45 PM, Tong Sun  wrote:
>>
>>> Oh, I misread the title. 
>>>
>>> But iota only change while defining constance. Assigning them to 
>>> variables will either get zero all the time, or Go need to define a very 
>>> complicated theme how iota change while defining variables, very 
>>> complicated I assume. 
>>>
>>>
>>>
>>> On Wednesday, May 3, 2017 at 10:39:47 AM UTC-4, T L wrote:



 On Wednesday, May 3, 2017 at 10:27:47 PM UTC+8, Tong Sun wrote:
>
> I have no problem assigning iota to variables. Can you elaborate a bit 
> pls? 
>

 package main

 var a = iota // undefined: iota

 func main(){
 var a = iota // undefined: iota
 }
  

>
> On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:
>>
>> .
>>
> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [go-nuts] Re: why iota can't be assigned to variables?

[T L]

On Wednesday, May 3, 2017 at 10:51:00 PM UTC+8, Axel Wagner wrote:
>
> I think it has been pointed out to you before, that go isn't a project 
> where "The request is not essential, but any harm of it?" is an acceptable 
> justification to add things.
>
> Or, to put it another way: Any addition has a harm, which is, that it's 
> complicating the language. You need to make your argument of why these 
> costs are justified.
>

isn't consistent a good argument? :)
 

>
> On Wed, May 3, 2017 at 4:45 PM, Tong Sun  > wrote:
>
>> Oh, I misread the title. 
>>
>> But iota only change while defining constance. Assigning them to 
>> variables will either get zero all the time, or Go need to define a very 
>> complicated theme how iota change while defining variables, very 
>> complicated I assume. 
>>
>>
>>
>> On Wednesday, May 3, 2017 at 10:39:47 AM UTC-4, T L wrote:
>>>
>>>
>>>
>>> On Wednesday, May 3, 2017 at 10:27:47 PM UTC+8, Tong Sun wrote:

 I have no problem assigning iota to variables. Can you elaborate a bit 
 pls? 

>>>
>>> package main
>>>
>>> var a = iota // undefined: iota
>>>
>>> func main(){
>>> var a = iota // undefined: iota
>>> }
>>>  
>>>

 On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:
>
> .
>
 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 4:38 PM T L  wrote:

> The request is not essential, but any harm of it?

How can anybody know that if nobody knows what it shall actually do and
what will be the impact on the complexity of the specification and
implementation?

-- 

-j

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

Re: [go-nuts] Re: Fully-qualified import paths and Pull Requests

['Axel Wagner' via golang-nuts]

Yes, that would be the correct approach. And yes, the fork wouldn't be
go-gettable, but it isn't supposed to be long-lived or go-got anyway; it's
a fork to do a pull-request.
If you want to do an actual fork (not what github calls a fork, but what
the open source community calls a fork), you are creating a new project
which should have a different name from the forked project and as such
should have the import paths rewritten.

On Wed, May 3, 2017 at 4:43 PM, st ov  wrote:

> In reading deeper, is the post saying to put my fork at the canonical path
> locally.
>
> So I'd clone my fork, *github.com/me/foo * to 
> *github.com/original/foo
> * *locally*
> But setup the git remote to push to *github.com/me/foo
> *
>
> Then locally, I would use the fully-qualified import path of
> import (
>  "github.com/original/foo/internal/bar
> "
> )
>
> Is that the right workflow?
> So now it should work locally and with the pull request, but won't the
> fork be broken? If for example, someone forks or clones my github repo the
> import path won't work?
>
>
>
> On Wednesday, May 3, 2017 at 7:33:49 AM UTC-7, st ov wrote:
>>
>> Thanks, if I read that right the post just rehashes the workflow for
>> working with remotes with git and go get.
>>
>> The question I have concerns the import path in the code.
>>
>> If I fork, *github.com/original/foo *
>> clone it locally to, *github.com/me/foo *
>> Add *github.com/me/foo/internal/bar/bar.go
>> * and the following import
>> statement to *github.com/me/foo/main.go
>> *
>>
>> // idiomatic fully-qualified import path
>> import (
>>  "github.com/me/foo/internal/bar"
>> )
>>
>> Commit and push to my remote fork, *github.com/me/foo
>> *
>>
>> Now if I submit the push request to *github.com/original/foo
>> *, the import statement will be broken
>> since the import path is to my repo, *github.com/me/foo
>> *.
>> If I change the import path in my repo to that of the original, then that
>> breaks my repo.
>>
>> How is this situation suppose to be handled when contributing?
>>
>>
>>
>> On Tuesday, May 2, 2017 at 11:55:41 PM UTC-7, Nathan Kerr wrote:
>>>
>>> http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives
>>> some good pointers on how to do this.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: why iota can't be assigned to variables?

[T L]

On Wednesday, May 3, 2017 at 10:45:09 PM UTC+8, Tong Sun wrote:
>
> Oh, I misread the title. 
>
> But iota only change while defining constance. Assigning them to variables 
> will either get zero all the time, or Go need to define a very complicated 
> theme how iota change while defining variables, very complicated I assume. 
>

Isn't it ok just like constant declarations?
 

>
>
> On Wednesday, May 3, 2017 at 10:39:47 AM UTC-4, T L wrote:
>>
>>
>>
>> On Wednesday, May 3, 2017 at 10:27:47 PM UTC+8, Tong Sun wrote:
>>>
>>> I have no problem assigning iota to variables. Can you elaborate a bit 
>>> pls? 
>>>
>>
>> package main
>>
>> var a = iota // undefined: iota
>>
>> func main(){
>> var a = iota // undefined: iota
>> }
>>  
>>
>>>
>>> On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:

 .

>>>

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

Re: [go-nuts] Re: why iota can't be assigned to variables?

['Axel Wagner' via golang-nuts]

I think it has been pointed out to you before, that go isn't a project
where "The request is not essential, but any harm of it?" is an acceptable
justification to add things.

Or, to put it another way: Any addition has a harm, which is, that it's
complicating the language. You need to make your argument of why these
costs are justified.

On Wed, May 3, 2017 at 4:45 PM, Tong Sun  wrote:

> Oh, I misread the title.
>
> But iota only change while defining constance. Assigning them to variables
> will either get zero all the time, or Go need to define a very complicated
> theme how iota change while defining variables, very complicated I assume.
>
>
>
> On Wednesday, May 3, 2017 at 10:39:47 AM UTC-4, T L wrote:
>>
>>
>>
>> On Wednesday, May 3, 2017 at 10:27:47 PM UTC+8, Tong Sun wrote:
>>>
>>> I have no problem assigning iota to variables. Can you elaborate a bit
>>> pls?
>>>
>>
>> package main
>>
>> var a = iota // undefined: iota
>>
>> func main(){
>> var a = iota // undefined: iota
>> }
>>
>>
>>>
>>> On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:

 .

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

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

[go-nuts] Re: why iota can't be assigned to variables?

[Tong Sun]

Oh, I misread the title. 

But iota only change while defining constance. Assigning them to variables 
will either get zero all the time, or Go need to define a very complicated 
theme how iota change while defining variables, very complicated I assume. 


On Wednesday, May 3, 2017 at 10:39:47 AM UTC-4, T L wrote:
>
>
>
> On Wednesday, May 3, 2017 at 10:27:47 PM UTC+8, Tong Sun wrote:
>>
>> I have no problem assigning iota to variables. Can you elaborate a bit 
>> pls? 
>>
>
> package main
>
> var a = iota // undefined: iota
>
> func main(){
> var a = iota // undefined: iota
> }
>  
>
>>
>> On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:
>>>
>>> .
>>>
>>

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

[go-nuts] Re: Fully-qualified import paths and Pull Requests

[st ov]

In reading deeper, is the post saying to put my fork at the canonical path 
locally.

So I'd clone my fork, *github.com/me/foo* to *github.com/original/foo* 
*locally*
But setup the git remote to push to *github.com/me/foo*

Then locally, I would use the fully-qualified import path of 
import (
 "github.com/original/foo/internal/bar 
" 
)

Is that the right workflow?
So now it should work locally and with the pull request, but won't the fork 
be broken? If for example, someone forks or clones my github repo the 
import path won't work?



On Wednesday, May 3, 2017 at 7:33:49 AM UTC-7, st ov wrote:
>
> Thanks, if I read that right the post just rehashes the workflow for 
> working with remotes with git and go get.
>
> The question I have concerns the import path in the code.
>
> If I fork, *github.com/original/foo *
> clone it locally to, *github.com/me/foo *
> Add *github.com/me/foo/internal/bar/bar.go 
> * and the following import 
> statement to *github.com/me/foo/main.go 
> *
>
> // idiomatic fully-qualified import path
> import (
>  "github.com/me/foo/internal/bar" 
> )
>
> Commit and push to my remote fork, *github.com/me/foo 
> *
>
> Now if I submit the push request to *github.com/original/foo 
> *, the import statement will be broken 
> since the import path is to my repo, *github.com/me/foo 
> *. 
> If I change the import path in my repo to that of the original, then that 
> breaks my repo.
>
> How is this situation suppose to be handled when contributing? 
>
>
>
> On Tuesday, May 2, 2017 at 11:55:41 PM UTC-7, Nathan Kerr wrote:
>>
>> http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives some 
>> good pointers on how to do this.
>
>

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

Re: [go-nuts] Re: Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 4:24 PM Piotr Narewski  wrote:

> I've just tried it and unfortunately it doesn't seem to be better than
the traditional approach.
>
> With the pool in place, it still user too much memory (unlike my solution
with using a heap via glibc).

Sorry to hear that. There are few things worth checking:

- slice.Put must be called once the slice will be no more used.
- The program may not keep any references to the slice passed to slice.Put.
- If you use append on the slice returned from slice.Get() you will
effectively stop using the pool as append can allocate a new backing array
but not by calling slice.Get/CGet. IOW, in such cases it's also necessary
to write one's own append ;-)

The best way to figure out where the memory consumption is happening when
using slice.Pool is to profile it, example:

$ go test -run @ -bench . -memprofile mem.out -memprofilerate 1
$ go tool pprof -lines -web -alloc_space *.test mem.out

-- 

-j

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

[go-nuts] Re: why iota can't be assigned to variables?

[T L]

On Wednesday, May 3, 2017 at 10:27:47 PM UTC+8, Tong Sun wrote:
>
> I have no problem assigning iota to variables. Can you elaborate a bit 
> pls? 
>

package main

var a = iota // undefined: iota

func main(){
var a = iota // undefined: iota
}
 

>
> On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:
>>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google 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] why iota can't be assigned to variables?

[T L]

On Wednesday, May 3, 2017 at 9:28:28 PM UTC+8, Jan Mercl wrote:
>
> On Wed, May 3, 2017 at 3:19 PM T L  
> wrote:
>
> Why would you want to assign iota to a variable? What value should iota in 
> such case have?
>
>
The request is not essential, but any harm of it?
 

>
> -- 
>
> -j
>

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

[go-nuts] Re: Fully-qualified import paths and Pull Requests

[st ov]

Thanks, if I read that right the post just rehashes the workflow for 
working with remotes with git and go get.

The question I have concerns the import path in the code.

If I fork, *github.com/original/foo*
clone it locally to, *github.com/me/foo*
Add *github.com/me/foo/internal/bar/bar.go* and the following import 
statement to *github.com/me/foo/main.go*

// idiomatic fully-qualified import path
import (
 "github.com/me/foo/internal/bar" 
)

Commit and push to my remote fork, *github.com/me/foo*

Now if I submit the push request to *github.com/original/foo*, the import 
statement will be broken since the import path is to my repo, 
*github.com/me/foo*. 
If I change the import path in my repo to that of the original, then that 
breaks my repo.

How is this situation suppose to be handled when contributing? 



On Tuesday, May 2, 2017 at 11:55:41 PM UTC-7, Nathan Kerr wrote:
>
> http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives some 
> good pointers on how to do this.

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

[go-nuts] Re: [ANN] listser/mutexer/channeler: generators.

[omarshariffdontlikeit]

Is the resulting generated code safe to use from multiple go routines?

On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote:
>
> Hi,
>
> several generators i made to avoid some duplication.
>
> https://github.com/mh-cbon/lister
>
> Package lister is a generator to generate typed slice.
>
>
> https://github.com/mh-cbon/channeler
>
> Package channeler is a cli generator to generate channeled version of a 
> type.
>
> https://github.com/mh-cbon/mutexer
>
> Package mutexer is a cli generator to generate mutexed version of a type.
>
>
> so basically, using below code you got hundreds of line generated for you,
>
>
> in that example to make a mutexed []Tomate.
>
>
> But as it s not too stupid, or tries too, it will be able to handle 
>
> pointer and basic types
>
> mutexed []*Tomate
>
> mutexed []string
>
> ect
>
>
> It should also be able to lookup for a constructor of the src type 
> (Tomate),
>
> and reproduce it into the dest type implementation.
>
>
> There is both mutexer / channeler because both cases applies for reasons.
>
>
> The lister is a convenient way to create typed slice.
>
>
> package demo
>
> // Tomate is about red vegetables to make famous italian food.
> type Tomate struct {
> Name string
> }
>
> // GetID return the ID of the Tomate.
> func (t Tomate) GetID() string {
> return t.Name
> }
>
> //go:generate lister vegetables_gen.go Tomate:Tomates
> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>
> hth
>
>

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

[go-nuts] Re: [ANN] listser/mutexer/channeler: generators.

[omarshariffdontlikeit]

This looks really good. Can anyone else recommend any other generators that 
produce lists/iterators like this?

On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote:
>
> Hi,
>
> several generators i made to avoid some duplication.
>
> https://github.com/mh-cbon/lister
>
> Package lister is a generator to generate typed slice.
>
>
> https://github.com/mh-cbon/channeler
>
> Package channeler is a cli generator to generate channeled version of a 
> type.
>
> https://github.com/mh-cbon/mutexer
>
> Package mutexer is a cli generator to generate mutexed version of a type.
>
>
> so basically, using below code you got hundreds of line generated for you,
>
>
> in that example to make a mutexed []Tomate.
>
>
> But as it s not too stupid, or tries too, it will be able to handle 
>
> pointer and basic types
>
> mutexed []*Tomate
>
> mutexed []string
>
> ect
>
>
> It should also be able to lookup for a constructor of the src type 
> (Tomate),
>
> and reproduce it into the dest type implementation.
>
>
> There is both mutexer / channeler because both cases applies for reasons.
>
>
> The lister is a convenient way to create typed slice.
>
>
> package demo
>
> // Tomate is about red vegetables to make famous italian food.
> type Tomate struct {
> Name string
> }
>
> // GetID return the ID of the Tomate.
> func (t Tomate) GetID() string {
> return t.Name
> }
>
> //go:generate lister vegetables_gen.go Tomate:Tomates
> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>
> hth
>
>

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

[go-nuts] Re: why iota can't be assigned to variables?

[Tong Sun]

I have no problem assigning iota to variables. Can you elaborate a bit pls? 

On Wednesday, May 3, 2017 at 9:19:46 AM UTC-4, T L wrote:
>
> .
>

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

[go-nuts] Re: Is there a way to fee a memory object on demand?

[Piotr Narewski]

OK, I get it.

I've just tried it and unfortunately it doesn't seem to be better than the 
traditional approach.

With the pool in place, it still user too much memory (unlike my solution 
with using a heap via glibc).

Anyway, thanks - it was worth trying.

On Wednesday, May 3, 2017 at 3:33:12 PM UTC+2, T L wrote:
>
> It would be great if it is possible that the collector only collect a 
> specified memory block groups.
> For example, runtime.GC(group []unsafe.Pointer), will only collect the 
> memory blocks only referenced by the group parameter.
>
> On Wednesday, May 3, 2017 at 2:35:43 AM UTC+8, Piotr Narewski wrote:
>>
>> My app uses large amounts of memory; it actively allocates and frees lots 
>> of slices.
>> I'm talking about gigabytes here.
>>
>> With the default GOGC=100 setting, it needs twice more memory.
>>
>> When I decrease GOGC to a lower value, it affects performance pretty 
>> badly.
>>
>> So far the best solution I have found is this:
>>
>> *
>> /*
>> #include 
>> */
>> import "C"
>>
>> func gcc_malloc(le uint32) unsafe.Pointer {
>> ptr := unsafe.Pointer(C.malloc(C.size_t(le+4)))
>> *((*uint32)(unsafe.Pointer(ptr))) = le
>> return ptr
>> }
>>
>> func gcc_free(ptr unsafe.Pointer) {
>> C.free(unsafe.Pointer(ptr))
>> }
>>
>> func gcc_len(ptr unsafe.Pointer) int {
>> return int(*((*uint32)(ptr)))
>> }
>>
>> func gcc_slice(ptr unsafe.Pointer) []byte {
>> le := gcc_len(ptr)
>> return 
>> *(*[]byte)(unsafe.Pointer({Data:uintptr(ptr)+4, Len:le, 
>> Cap:le}))
>> }
>> *
>>
>> So if I need a new slice to store a data, I do:
>>  slice := gcc_slice(gcc_malloc( HOW_MANY_BYTES ))
>>
>> Then, when I no longer need this slice, I just do something like:
>>  gcc_free(unsafe.Pointer())
>>
>> It works and performs very well, but I have a problem with compatibility 
>> on different platforms.
>> For instance, it needs gcc compiler...
>>
>> Does anyone know a way to do something like this (freeing memory on 
>> demand), but using pure Go?
>> Something that will compile (and work) on any platform, without any extra 
>> dependencies..
>>
>>

-- 
You received this message because you are subscribed to the Google 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: http: TLS handshake error from :: EOF

[James Hartig]

We're also seeing 100k of these errors per day per server. The majority of 
the time its just a result of:
client SYN
server SYN-ACK
client FIN
server FIN-ACK

or
 
client SYN
server SYN-ACK
Retransmission
Retransmission
RST
...

The error if the version is unsupported is:
http: TLS handshake error from ip:port : tls: client offered an 
unsupported, maximum protocol version of 300

Can we ignore this error if there was no handshake ever initiated?

Thanks!

On Sunday, January 1, 2017 at 1:10:54 PM UTC-5, paperboardinc wrote:
>
> No worries J at least your trying to help. I think the minimum must be 
> TLS 1.0 because I know I didn’t set the tls server config value, however, I 
> do know exactly where to set it. I asked this question in the Go repo on 
> Github, a core golang developer told me to use the forums for asking 
> questions, I suppose he knows the answer since he wasn’t really surprised 
> about the behavior. We have about 2 million people using the site on a 
> monthly basis, so it really floods our logs. @bratfpatrick please help!
>
>  
>
>

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

[go-nuts] Re: Is there a way to fee a memory object on demand?

[T L]

It would be great if it is possible that the collector only collect a 
specified memory block groups.
For example, runtime.GC(group []unsafe.Pointer), will only collect the 
memory blocks only referenced by the group parameter.

On Wednesday, May 3, 2017 at 2:35:43 AM UTC+8, Piotr Narewski wrote:
>
> My app uses large amounts of memory; it actively allocates and frees lots 
> of slices.
> I'm talking about gigabytes here.
>
> With the default GOGC=100 setting, it needs twice more memory.
>
> When I decrease GOGC to a lower value, it affects performance pretty badly.
>
> So far the best solution I have found is this:
>
> *
> /*
> #include 
> */
> import "C"
>
> func gcc_malloc(le uint32) unsafe.Pointer {
> ptr := unsafe.Pointer(C.malloc(C.size_t(le+4)))
> *((*uint32)(unsafe.Pointer(ptr))) = le
> return ptr
> }
>
> func gcc_free(ptr unsafe.Pointer) {
> C.free(unsafe.Pointer(ptr))
> }
>
> func gcc_len(ptr unsafe.Pointer) int {
> return int(*((*uint32)(ptr)))
> }
>
> func gcc_slice(ptr unsafe.Pointer) []byte {
> le := gcc_len(ptr)
> return *(*[]byte)(unsafe.Pointer({Data:uintptr(ptr)+4, 
> Len:le, Cap:le}))
> }
> *
>
> So if I need a new slice to store a data, I do:
>  slice := gcc_slice(gcc_malloc( HOW_MANY_BYTES ))
>
> Then, when I no longer need this slice, I just do something like:
>  gcc_free(unsafe.Pointer())
>
> It works and performs very well, but I have a problem with compatibility 
> on different platforms.
> For instance, it needs gcc compiler...
>
> Does anyone know a way to do something like this (freeing memory on 
> demand), but using pure Go?
> Something that will compile (and work) on any platform, without any extra 
> dependencies..
>
>

-- 
You received this message because you are subscribed to the Google 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] why iota can't be assigned to variables?

[Jan Mercl]

On Wed, May 3, 2017 at 3:19 PM T L  wrote:

Why would you want to assign iota to a variable? What value should iota in
such case have?


-- 

-j

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

Re: [go-nuts] Is there a way to fee a memory object on demand?

[Jan Mercl]

On Wed, May 3, 2017 at 3:14 PM Piotr Narewski  wrote:

> Wouldn't it require me to only use slices of a fixed size?

No, the slice.Pool object has 63 sync.Pool objects:
https://github.com/cznic/internal/blob/e5e1c3e9165d0a72507c2bbb0ffac1c02b8d3f7c/slice/pool.go#L95,
ie. 63 buckets, one for each log_2(size). Get and Put work on the bucket
selected by the request size (Get) or the capacity of the slice passed
(Put).
-- 

-j

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

[go-nuts] Re: ...interface{} vs interface{} + reflection

[Jonathan Hall]

Nice find wrt: mgo. That is a good analogy.

And thanks for your input.  That is a good observation that it could also 
save some internal conversion.

-- Jonathan

On Tuesday, May 2, 2017 at 8:12:39 PM UTC+2, Jonathan Hall wrote:
>
> I have a public API that takes `...interface{}` as an argument.  (For 
> reference: https://godoc.org/github.com/flimzy/kivik#DB.BulkDocs )
>
> I'm considering changing this to instead take `interface{}` as an 
> argument, then using reflection to:
>
>   - Validate that the underlying type is an array
>   - Convert to `[]interface{}` before using it internally
>
> The reason I'm considering the change is that the normal use-case for the 
> function is on an array of specifically-typed documents, and converting to 
> `[]interface{}` before every call is cumbersome, and redundant ~95%+ of the 
> time.
>
> I'm wondering if I might be overlooking any obvious drawbacks to this 
> approach.  Thus far, my hesitation comes from the following facts:
>
> - Using reflection to check that an argument is an array seems sloppy 
> (although I've seen it before). It loses all benefits of compile-time 
> checking
> - Using reflection for the conversion is presumably slower than doing the 
> conversion in the caller.
>
> Are there other pros or cons I'm not considering that I should take into 
> account when deciding how to proceed?
>
> Much thanks,
>
> -- Jonathan
>
>

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

[go-nuts] why iota can't be assigned to variables?

[T L]

.

-- 
You received this message because you are subscribed to the Google 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 there a way to fee a memory object on demand?

[Piotr Narewski]

Thanks.

Sorry, but I don't quite get this usage example.

Wouldn't it require me to only use slices of a fixed size?



On Tuesday, May 2, 2017 at 9:30:45 PM UTC+2, Jan Mercl wrote:
>
> On Tue, May 2, 2017 at 8:35 PM Piotr Narewski  > wrote:
>
> > Does anyone know a way to do something like this (freeing memory on 
> demand), but using pure Go?
> > Something that will compile (and work) on any platform, without any 
> extra dependencies..
>
> sync.Pool could be probably a good fit. Usage example: 
> https://github.com/cznic/internal/blob/e5e1c3e9165d0a72507c2bbb0ffac1c02b8d3f7c/slice/pool.go
> -- 
>
> -j
>

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

[go-nuts] Re: bug or not?

[pierre . curto]

RHS = right hand side
LHS = left hand side

Le mercredi 3 mai 2017 14:53:40 UTC+2, mhh...@gmail.com a écrit :
>
> similarly, it is possible to rewrite len, or a package id. 
>
> I got caught some times about that, 
> since then i take care about that.
>
> but yeah, feels weird.
>
> btw, what means RHS / LHS in ast package and in the comment by cznic ?
> many times i read it and wonder..
>
> On Wednesday, May 3, 2017 at 2:32:47 PM UTC+2, T L wrote:
>>
>> https://github.com/golang/go/issues/20219
>>
>>
>>

-- 
You received this message because you are subscribed to the Google 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 get -u doesn't update dependencies

[anatoly techtonik]

I am pretty sure GOPATH is correct. There are also no symlinks. Unless
`go` created them itself.

On Tue, May 2, 2017 at 11:35 AM, Dave Cheney  wrote:
> One cause can be an incorrect GOPATH setting (if the source is outside
> GOPATH, possibly due to symlinks)
>
>
> On Tuesday, 2 May 2017 18:33:34 UTC+10, anatoly techtonik wrote:
>>
>> https://github.com/lxc/lxd/pull/3260 was an attempt to prevent breaking
>> builds due to a missing/updated dependency with `go get -u`. However, this
>> command didn't fetch it. Why? Why not to fix it?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/oHmKAMp-ecY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
anatoly t.

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

[go-nuts] Re: bug or not?

[mhhcbon]

similarly, it is possible to rewrite len, or a package id. 

I got caught some times about that, 
since then i take care about that.

but yeah, feels weird.

btw, what means RHS / LHS in ast package and in the comment by cznic ?
many times i read it and wonder..

On Wednesday, May 3, 2017 at 2:32:47 PM UTC+2, T L wrote:
>
> https://github.com/golang/go/issues/20219
>
>
>

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

[go-nuts] Re: No Allman-Style, No go!

[ecstatic . coder]

BTW, I've just released Genesis, an open source generic preprocessor which 
automatically converts Allman style code into K and allows genericity by 
parametric instantiation.

https://github.com/senselogic/GENESIS

Better late than never... ;)

On Saturday, September 21, 2013 at 3:58:03 AM UTC+2, Michael Daconta wrote:
>
> Hi Go fans,
>
> I frankly was shocked to learn that a program like:
>
> package main;
>
> import "fmt";
>
> func main() 
> {
> fmt.Printf("hello, world!\n");
> }
>
> ... is currently illegal in go with the error:
>
> # command-line-arguments
> .\hello.go:6: syntax error: unexpected semicolon or newline before {
>
> From reading the newsgroups, I see that this is illegal due to the 
> automatic insertion of semi-colons; however, what if I added my own 
> semi-colons into the code as in the above.  From a language perspective the 
> above should be legal Go code.  To me, it seems like a hack for convenience 
> (making semi-colons optional) has forced a K style on everyone.
> For me, this is a show-stopper.  Frankly, I am surprised that Google would 
> enforce a coding style (K) while saying that "go fmt" frees you from 
> worrying about divergent coding styles.  Sorry, google - you cannot have it 
> both ways.  Unless the Allman-style code above is illegal in the language 
> (which makes no sense from a language semantics point of view) - get the 
> compiler to accept it. Period.
>
> Yes, I know I can write my own translator - but why?  Heck, I can just 
> stick with Java...
>
> C'mon Google, when trying to pitch a new language, you can (and should) do 
> better than this...
>
> - Mike
>

-- 
You received this message because you are subscribed to the Google 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: Sorting an array of time.Duration

[Michael Jones]

Ram,

Here is another example, a slightly modified version of ojucie's program:

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

The difference here is to show the idea of making a custom type this is
simply for the  purpose of defining extra behaviors, such as those needed
by Sort.

On Tue, May 2, 2017 at 1:50 PM,  wrote:

> Thank you JuciÊ Andrade & Roberto.
>
>
> On Tuesday, May 2, 2017 at 12:07:19 PM UTC-7, JuciÊ Andrade wrote:
>>
>> From Go v1.8 onwards there is yet another alternative: you can use the
>> sort package without implementing the Sort interface.
>>
>> Example:
>>
>> https://play.golang.org/p/YmiWpshLlX
>>
> --
> You received this message because you are subscribed to the Google 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.

[go-nuts] bug or not?

[T L]

https://github.com/golang/go/issues/20219


-- 
You received this message because you are subscribed to the Google 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] ...interface{} vs interface{} + reflection

[roger peppe]

I'd say your case isn't dissimilar to this one:
https://godoc.org/gopkg.in/mgo.v2#Iter.All

>From a brief glance at your code, I'd think that using interface{}
rather than []interface{}
is a reasonable approach. It could actually save the conversion to
[]interface{} completely
in some places (for example in the couchdb driver, the  "docs" field
could have the
typed slice as an argument rather than the []interface{}, because the
whole thing
is encoded to JSON)

  cheers,
rog.

On 2 May 2017 at 19:12, Jonathan Hall  wrote:
> I have a public API that takes `...interface{}` as an argument.  (For
> reference: https://godoc.org/github.com/flimzy/kivik#DB.BulkDocs )
>
> I'm considering changing this to instead take `interface{}` as an argument,
> then using reflection to:
>
>   - Validate that the underlying type is an array
>   - Convert to `[]interface{}` before using it internally
>
> The reason I'm considering the change is that the normal use-case for the
> function is on an array of specifically-typed documents, and converting to
> `[]interface{}` before every call is cumbersome, and redundant ~95%+ of the
> time.
>
> I'm wondering if I might be overlooking any obvious drawbacks to this
> approach.  Thus far, my hesitation comes from the following facts:
>
> - Using reflection to check that an argument is an array seems sloppy
> (although I've seen it before). It loses all benefits of compile-time
> checking
> - Using reflection for the conversion is presumably slower than doing the
> conversion in the caller.
>
> Are there other pros or cons I'm not considering that I should take into
> account when deciding how to proceed?
>
> Much thanks,
>
> -- Jonathan
>
> --
> You received this message because you are subscribed to the Google 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: Will deleting a key from a map in an iteration prevent some keys being iterated in the same iteration?

[T L]

On Tuesday, May 2, 2017 at 10:07:11 PM UTC+8, Keith Randall wrote:
>
> Yes, all keys present in the map at the start of iteration, that aren't 
> deleted during iteration, will be returned during iteration.
>

Thanks for the clarification.
 

>
> On Monday, May 1, 2017 at 4:51:56 AM UTC-4, T L wrote:
>>
>>
>>
>> On Monday, May 1, 2017 at 3:56:51 PM UTC+8, Paul Jolly wrote:
>>>
>>> I think the part of the spec you're after is under the heading: 
>>> https://golang.org/ref/spec#For_statements, specifically the 
>>> sub-heading of that link "For statements with range clause", specifically 
>>> point 3 in the enumerated list:
>>>
>>> *The iteration order over maps is not specified and is not guaranteed to 
 be the same from one iteration to the next. If map entries that have not 
 yet been reached are removed during iteration, the corresponding iteration 
 values will not be produced. If map entries are created during iteration, 
 that entry may be produced during the iteration or may be skipped. The 
 choice may vary for each entry created and from one iteration to the next. 
 If the map is nil, the number of iterations is 0.*
>>>
>>>
>>>
>>>
>>>
>> The guarantee I need is *every map entries created before the iteration 
>> will be reached if it is not removed even if some entries are removed in 
>> the iteration*.
>> Looks this is silly. :) The answer should be yes I think.
>>  
>>
>>>
>>> On 1 May 2017 at 08:51, T L  wrote:
>>>


 On Monday, May 1, 2017 at 3:50:11 PM UTC+8, T L wrote:
>
> for example
>
> for k, v := range m {
> if SatisfySomeCondition(k, v) {
> delete(m, k)
> }
> }
>
> will the above iteration guarantee to delete all k-v pairs from m?
>

  will the above iteration guarantee to delete all k-v pairs satisfying 
 a condition from m?

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

>>>
>>>

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

Re: [go-nuts] Re: iota with gaps

[mhhcbon]

indeed, totally misleading for me,

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

On Wednesday, May 3, 2017 at 1:05:35 PM UTC+2, rog wrote:
>
> On 3 May 2017 at 09:36, Egon  wrote: 
> > On Wednesday, 3 May 2017 07:34:16 UTC+3, Tong Sun wrote: 
> >> 
> >> Hi, 
> >> 
> >> How to use `iota` to define consts that have gap(s) in them? 
> >> 
> >> E.g., If my consts are, 
> >> 
> >> 1, 2, 3, 7, 8, 9 
> >> 
> >> How to use iota to define them? Thx. 
> > 
> > 
> > You don't have to use iota. If these are predefined constants, such as a 
> > protocol -- it's usually better to assign them explicitly rather than to 
> use 
> > iota. 
> > 
> > There are also: 
> > 
> > // use skip 
> > const ( 
> > A = iota 
> > B 
> > C 
> > D = iota + 3 // for skip 3 
>
> I think this is slightly misleading - this idiom doesn't 
> skip three - it adds 3 to the current value of iota. 
>
> For example, given 
>
>const ( 
>A = iota 
>B 
>C 
>D = iota + 10 
>E 
>F = iota + 2 
>G 
>) 
>
> G will be 8, not 18. 
>

-- 
You received this message because you are subscribed to the Google 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] Errors from Gob

[Chris Hopkins]

Yeah until the comment about NFS I hadn't thought that the file system
would be generating those errors and passing that through to Gob back to
me. Silly in retrospect, sorry.

I wasn't aware of that architecture that there was a mapping within Go from
the error number to an error string.

Could I check with the community what the best practice on this should be?
Should I be searching through error strings for expected error messages, or
should there be another method?
My understanding was that best practice for packages was to declare each
error as its own constant that could then be checked for. e.g. like io has
an EOF constant, I assumed that best practice was that packages should
declare and export those.
This would imply that the syscall package should be modified to export each
of these error types as constants that can be checked for?

FWIW I think there may be an error message mis-map as breaking the calls
into 1k size has removed the error. When I get the chance I'll try and
investigate more, but the depths of syscalls is outside my comfort zone.

Thanks

Chris


On 30 April 2017 at 01:41, Lars Seipel  wrote:

> On Thu, Apr 27, 2017 at 08:55:36AM -0700, Chris Hopkins wrote:
> > What's the current thinking on this sort of error handling? It's hard to
> > say "Handle errors properly" when the standard library is butchering the
> > original error message.
>
> This most likely *is* the original error, as returned by your system.
> It corresponds to the EHOSTDOWN error code and was apparently
> encountered during a write system call.
>
> The system call interface on Unix just doesn't give you any more than
> this. You need to look up the conditions under which your system might
> return that particular error code.
>
> If you really think the message is bogus, you might want to compare the
> errno-to-errstr mapping in package syscall against your local system
> headers. This is going to depend on OS and arch, of course.
>

-- 
You received this message because you are subscribed to the Google 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: iota with gaps

[roger peppe]

On 3 May 2017 at 09:36, Egon  wrote:
> On Wednesday, 3 May 2017 07:34:16 UTC+3, Tong Sun wrote:
>>
>> Hi,
>>
>> How to use `iota` to define consts that have gap(s) in them?
>>
>> E.g., If my consts are,
>>
>> 1, 2, 3, 7, 8, 9
>>
>> How to use iota to define them? Thx.
>
>
> You don't have to use iota. If these are predefined constants, such as a
> protocol -- it's usually better to assign them explicitly rather than to use
> iota.
>
> There are also:
>
> // use skip
> const (
> A = iota
> B
> C
> D = iota + 3 // for skip 3

I think this is slightly misleading - this idiom doesn't
skip three - it adds 3 to the current value of iota.

For example, given

   const (
   A = iota
   B
   C
   D = iota + 10
   E
   F = iota + 2
   G
   )

G will be 8, not 18.

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

[go-nuts] [ANN] the busy man: init repo quickly

[mhhcbon]

Hi,

made that because i was super lazy...

https://github.com/mh-cbon/the-busy-man

So now i can do,

1/ add an alias of my preferred repo init,

$ cat <> ~/.bashrcalias tbm="the-busy-man git:init license:mit 
emd:mh-cbon/emd golang gump:mh-cbon/gump git:commit changelog 
git:commit+amend"EOTsource ~/.bashrc

2/ run `tbm` into a directory to get a package ready to code

For plugins such a `license`, `emd` ect,
they rely on external go bin, 
so the program will install them via go get,
BUT, take care its HEAD everywhere (not so great.)

its not a bultin pipe of init 
because everyone is doing something
a bit different of his neighbor
so i suggest you pr  plugins for your needs.

A basic miss is the Makefile, because i m not Makefile user,
the idea would be to add a new plugin named `make`
and let it receive an intent such `cznic/sqlite`
and the program would init the makefile using the file existing in the repo
https://github.com/cznic/sqlite/blob/master/Makefile

Its basically what i shown in my alias with plugins like emd/gump.

hth

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

[go-nuts] Re: Fully-qualified import paths and Pull Requests

[mhhcbon]

Thanks!

Alright, i need to test that, im not used to HG, bzr. Kind of forgotten 
about svn (:/)


meanwhile,

https://github.com/mh-cbon/fork

On Wednesday, May 3, 2017 at 12:19:07 PM UTC+2, Dave Cheney wrote:
>
> You can simulate this with most source control systems by manually 
> checking out your fork in the original location.
>
> Say
>
> hg clone https://bitbucket.org/davecheney/pkg $GOPATH/src/
> bitbucket.org/project/pkg
>
>

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

[go-nuts] Re: Fully-qualified import paths and Pull Requests

[Dave Cheney]

You can simulate this with most source control systems by manually checking out 
your fork in the original location.

Say

hg clone https://bitbucket.org/davecheney/pkg 
$GOPATH/src/bitbucket.org/project/pkg

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

[go-nuts] Re: Fully-qualified import paths and Pull Requests

[mhhcbon]

Do you have any idea how that d work with other vcs ?



On Wednesday, May 3, 2017 at 8:55:41 AM UTC+2, Nathan Kerr wrote:
>
> http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives some 
> good pointers on how to do this.

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

[go-nuts] Re: iota with gaps

[Egon]

On Wednesday, 3 May 2017 07:34:16 UTC+3, Tong Sun wrote:
>
> Hi, 
>
> How to use `iota` to define consts that have gap(s) in them? 
>
> E.g., If my consts are, 
>
> 1, 2, 3, 7, 8, 9
>
> How to use iota to define them? Thx. 
>

You don't have to use iota. If these are predefined constants, such as a 
protocol -- it's usually better to assign them explicitly rather than to 
use iota.

There are also:

// use skip
const (
A = iota
B
C
D = iota + 3 // for skip 3
E
) // 0, 1, 2, 6, 7

// use multiple iotas
const (
A = iota
B
C
)
const (
D = iota + 100 // new iota starting from 100
E
) // 0, 1, 2, 100, 101

+ Egon

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

[go-nuts] go/mobile: is it possible to publish go build ios app on appstore?

[hui zhang]

Here is a document to show how to publish go build app on google play
https://pt.slideshare.net/takuyaueda967/go-for-mobile-games

However ,  there is no document on how to publish go build app on app store

how to do this,  is it possible ?
And it is much easier to integrate ios framework than jar pakcage.

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

[go-nuts] Re: Feedback welcome: "Shorten your URL"

[Nathan Kerr]

There are also responses here:  Feedback Welcome: ‘Shorten your URL’   
   


On Tuesday, May 2, 2017 at 9:32:45 AM UTC+2, Lutz Horn wrote:
>
> Hi Go Nuts, 
>
> to practice my Go skills, I've implemented a simple web application that 
> allows you to shorten an URL. The application consists of a backend 
> written in Go and a web frontend using jQuery with some plugins and 
> Bootstrap for layout. 
>
> The code is available on GitHub at https://github.com/lutzhorn/shorturl, 
> the application is deployed on https://u.lhorn.de. 
>
> I would very much appreciate any feedback you can give especially on the 
> Go part. Coming from a Java and Python background, I'm trying to get 
> into the Go way of programming, In Python there is a 'Pythonic' way to 
> write code, I am sure there is something similar in Go: File structure, 
> name choice, exporting names, error handling, ... 
>
> If you have a little time, please tak a look at the code, play with the 
> deployed application, and please give me feedback. 
>
> Thanks! 
>
> Lutz 
>
>
>

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

[go-nuts] Fully-qualified import paths and Pull Requests

[Nathan Kerr]

http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives some good 
pointers on how to do this.

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

[go-nuts] openid connect

[Nathan Kerr]

Try using https://github.com/markbates/goth

-- 
You received this message because you are subscribed to the Google 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.