Re: [go-nuts] When initializing variables, copies of values are made?

[Ian Lance Taylor]

On Thu, Jan 31, 2019 at 4:48 PM 伊藤和也  wrote:
>
> When initializing variables, If the copies of values are made,  their memory 
> usages will be:
>
>> var a = [3]int8{2, 4, 6}
>>|  |
>>
>>  3 bytes + 3 bytes = 6 bytes
>
>
>> var b = []int8[2, 4, 6}
>>|   |
>> 24 bytes + 24 bytes = 48 bytes
>
>
>> var c = func() {}
>>   | |
>>  8 bytes + 8 bytes = 16 bytes
>
>
>> var d = struct{n1 int, n2 int}{1, 2}
>>| |
>> 16 bytes   +   16 bytes = 32 bytes

If you want to understand the memory requirements of Go code at this
level, you need to read the generated assembly code.  You can't reason
about this kind of memory usage from first principles from the spec.
The spec does not impose any requirements on values in transit between
variables.

Ian

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

Re: [go-nuts] Re: When initializing variables, copies of values are made?

[Kurtis Rader]

On Thu, Jan 31, 2019 at 8:46 PM 伊藤和也  wrote:

> So in Go,
> The meaning of "declare" is allocate memory for a variable and initialize
> the variable explicitly or implicitly.
> e.g.
> var a int = 3   // "a" is explicitly initialized
> var b int // "b" is implicitly initialized
>

You should spend some time reading the language specification. In this case
https://golang.org/ref/spec#Variable_declarations and other relevant
documents such as https://gobyexample.com/variables. Variable `b` in your
example is initialized to the appropriate "zero" value for its type. This
is behavior is meant to address one of the major flaws of C/C++ where
function (i.e., stack) local vars which are not explicitly initialized have
a random initial value based on the content of the stack at that juncture.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

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

Re: [go-nuts] lock for assigning to different elements of an array

[johnmrusk]

>
> Writing to adjacent memory locations [i.e. different array elements, from 
> different goroutines] will cause false sharing between CPU caches. This is 
> a performance, not a correctness issue. 
>

I'm looking to make an array of thread-safe counters - each counting a 
different thing.  I propose to use an ordinary array, of fixed size, with 
thread safety coming solely from use of atomic operations to increment the 
values.  Will it be correct, but prone to false sharing between caches?

-- 
You received this message because you are subscribed to the Google 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: When initializing variables, copies of values are made?

[伊藤和也]

So in Go, 
The meaning of "declare" is allocate memory for a variable and initialize 
the variable explicitly or implicitly.
e.g.
var a int = 3   // "a" is explicitly initialized
var b int // "b" is implicitly initialized

The meaning of "assign" is give a copy of a value to a variable
e.g.
a = 300 // "a" gets the copy of "300"
b = a // "b" gets the copy of "300" of  "a"

2019年2月1日金曜日 9時48分34秒 UTC+9 伊藤和也:
>
> When initializing variables, If the copies of values are made,  their 
> memory usages will be:
>
> var a = [3]int8{2, 4, 6}
>>|  |
>
>  3 bytes + 3 bytes = 6 bytes
>
>
> var b = []int8[2, 4, 6}
>>|   |
>> 24 bytes + 24 bytes = 48 bytes
>
>
> var c = func() {}
>>   | |
>>  8 bytes + 8 bytes = 16 bytes 
>
>
> var d = struct{n1 int, n2 int}{1, 2}
>>| |
>> 16 bytes   +   16 bytes = 32 bytes
>
>

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

[go-nuts] using docker for compiling

[Keith Brown]

does anyone use docker golang image to compile? if so,how is your setup?

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

Re: [go-nuts] When initializing variables, copies of values are made?

[Michael Jones]

No. These are variable declarations not assignment statements.

In the assignment “a = b” there is a copy implied but for the variable
declaration the “=“ should not be read as “is copied to” but rather “of
this kind”.

var a is of the kind [3]bytes which happen to be 2, 4, and 6.

Size = 3

Second is similar

var b is of the kind [as many as initializers]bytes which happen to be 2,
4, and 6, so three bytes.

Size = 3

On Thu, Jan 31, 2019 at 4:48 PM 伊藤和也  wrote:

> When initializing variables, If the copies of values are made,  their
> memory usages will be:
>
> var a = [3]int8{2, 4, 6}
>>|  |
>
>  3 bytes + 3 bytes = 6 bytes
>
>
> var b = []int8[2, 4, 6}
>>|   |
>> 24 bytes + 24 bytes = 48 bytes
>
>
> var c = func() {}
>>   | |
>>  8 bytes + 8 bytes = 16 bytes
>
>
> var d = struct{n1 int, n2 int}{1, 2}
>>| |
>> 16 bytes   +   16 bytes = 32 bytes
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.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] When initializing variables, copies of values are made?

[伊藤和也]

When initializing variables, If the copies of values are made,  their 
memory usages will be:

var a = [3]int8{2, 4, 6}
>|  |

 3 bytes + 3 bytes = 6 bytes


var b = []int8[2, 4, 6}
>|   |
> 24 bytes + 24 bytes = 48 bytes


var c = func() {}
>   | |
>  8 bytes + 8 bytes = 16 bytes 


var d = struct{n1 int, n2 int}{1, 2}
>| |
> 16 bytes   +   16 bytes = 32 bytes

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

Re: [go-nuts] Existing code for order-preserving concurrent work queue?

[Bakul Shah]

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

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

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

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

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

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

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

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

Re: [go-nuts] Re: Existing code for order-preserving concurrent work queue?

[Michael Jones]

You deserve extra credit for getting the phrase "ouroboros data structure"
in there. ;-)

On Thu, Jan 31, 2019 at 10:20 AM roger peppe  wrote:

> On Thu, 31 Jan 2019 at 16:22, Michael Jones 
> wrote:
>
>> Agree. I’ve never had that level of imbalance but yes.
>>
>
> When doing mathematical calculations, as I think your code was, I think
> it's usual to have comparable costs for each item. By contrast, I'm usually
> adding this kind of code to make concurrent network requests, and in that
> scenario it's much more likely that some requests are orders of magnitude
> slower than others.
>
> FWIW I was quite pleased with the `chan chan R` idea - I might use it for
> real some time :) Come to think of it, it's slightly reminiscent of another
> pattern I wrote about some years ago:
> https://rogpeppe.wordpress.com/2009/12/01/concurrent-idioms-1-broadcasting-values-in-go-with-linked-channels/
>
>   cheers,
> rog.
>
>
>> On Thu, Jan 31, 2019 at 4:06 AM roger peppe  wrote:
>>
>>> On Thu, 31 Jan 2019 at 00:06, Michael Jones 
>>> wrote:
>>>
 note that my code sidesteps this problem generally

>>>
>>> I'm not sure that that's true. Although your code mitigates the problem
>>> somewhat,
>>> it's still possible for a one slow worker to block the others. You've
>>> added 512*NumCPU/2
>>> buffer slots, but in general it's not possible to order results and
>>> provide avoid unnecessary
>>> blocking without having N buffer slots. In your code, assume 4 CPUs and
>>> that work items 0
>>> and 2 take 1s and all other work items take 1ms. If we've got 5000 items
>>> in total,
>>> the total time taken will be 2.002498s instead of the ideal time
>>> (~1s+2499µs).
>>>
>>> https://play.golang.org/p/5Ty6pgpmZ0w
>>>
>>> Here's a kind of hybrid approach. It still serializes, but it makes as
>>> good a use of the buffer
>>> space as it can - it won't block until a slow item is at least bufSize
>>> items behind the
>>> most recently processed item:
>>>
>>> https://play.golang.org/p/PP9NSJuLeEK
>>>
>>>
 On Wed, Jan 30, 2019 at 3:48 PM roger peppe  wrote:

> On Wed, 30 Jan 2019 at 20:07, 'Bryan Mills' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> The code to sequence the results using a channel is not much more
>> verbose.
>>
>> That not only avoids the library dependency, but also makes the peak
>> memory consumption for the results O(runtime.NumCPU()), instead of O(N)
>> with the number of tasks, and allows the output to be streamed instead of
>> buffered to a slice.
>>
>> https://play.golang.org/p/zkBjxlcvESe
>>
>
> Nice! In practice though, I've usually found that I do want to keep
> the results around or I don't care about the order at all, so the parallel
> package works OK.
>
> I'd point out one down side to the sequencing approach - one very slow
> work item can block the others. For example, NProc is 4, the first item
> takes 200 milliseconds to process and all the others take 1 millisecond,
> then the first 4 workers have started, none more will be started until the
> first has, so the overall time will be quite a bit longer (249ms) than if
> they were all allowed to proceed irrespective of order (200ms).
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


 --

 *Michael T. jonesmichael.jo...@gmail.com *

>>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com *
>>
>

-- 

*Michael T. jonesmichael.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.

Re: [go-nuts] Re: Existing code for order-preserving concurrent work queue?

[roger peppe]

On Thu, 31 Jan 2019 at 16:22, Michael Jones  wrote:

> Agree. I’ve never had that level of imbalance but yes.
>

When doing mathematical calculations, as I think your code was, I think
it's usual to have comparable costs for each item. By contrast, I'm usually
adding this kind of code to make concurrent network requests, and in that
scenario it's much more likely that some requests are orders of magnitude
slower than others.

FWIW I was quite pleased with the `chan chan R` idea - I might use it for
real some time :) Come to think of it, it's slightly reminiscent of another
pattern I wrote about some years ago:
https://rogpeppe.wordpress.com/2009/12/01/concurrent-idioms-1-broadcasting-values-in-go-with-linked-channels/

  cheers,
rog.


> On Thu, Jan 31, 2019 at 4:06 AM roger peppe  wrote:
>
>> On Thu, 31 Jan 2019 at 00:06, Michael Jones 
>> wrote:
>>
>>> note that my code sidesteps this problem generally
>>>
>>
>> I'm not sure that that's true. Although your code mitigates the problem
>> somewhat,
>> it's still possible for a one slow worker to block the others. You've
>> added 512*NumCPU/2
>> buffer slots, but in general it's not possible to order results and
>> provide avoid unnecessary
>> blocking without having N buffer slots. In your code, assume 4 CPUs and
>> that work items 0
>> and 2 take 1s and all other work items take 1ms. If we've got 5000 items
>> in total,
>> the total time taken will be 2.002498s instead of the ideal time
>> (~1s+2499µs).
>>
>> https://play.golang.org/p/5Ty6pgpmZ0w
>>
>> Here's a kind of hybrid approach. It still serializes, but it makes as
>> good a use of the buffer
>> space as it can - it won't block until a slow item is at least bufSize
>> items behind the
>> most recently processed item:
>>
>> https://play.golang.org/p/PP9NSJuLeEK
>>
>>
>>> On Wed, Jan 30, 2019 at 3:48 PM roger peppe  wrote:
>>>
 On Wed, 30 Jan 2019 at 20:07, 'Bryan Mills' via golang-nuts <
 golang-nuts@googlegroups.com> wrote:

> The code to sequence the results using a channel is not much more
> verbose.
>
> That not only avoids the library dependency, but also makes the peak
> memory consumption for the results O(runtime.NumCPU()), instead of O(N)
> with the number of tasks, and allows the output to be streamed instead of
> buffered to a slice.
>
> https://play.golang.org/p/zkBjxlcvESe
>

 Nice! In practice though, I've usually found that I do want to keep the
 results around or I don't care about the order at all, so the parallel
 package works OK.

 I'd point out one down side to the sequencing approach - one very slow
 work item can block the others. For example, NProc is 4, the first item
 takes 200 milliseconds to process and all the others take 1 millisecond,
 then the first 4 workers have started, none more will be started until the
 first has, so the overall time will be quite a bit longer (249ms) than if
 they were all allowed to proceed irrespective of order (200ms).

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

>>>
>>>
>>> --
>>>
>>> *Michael T. jonesmichael.jo...@gmail.com *
>>>
>> --
>
> *Michael T. jonesmichael.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] Re: [ANN] goey - Declarative, cross-platform GUIs

[Robert Johnstone]

Hello,

Thank you for filing the two issues.  Both have been resolved.  Hopefully 
you won't find any other bugs... but if you do, please file an issue.

Robert


On Tuesday, 29 January 2019 16:15:01 UTC-5, Jake Montgomery wrote:
>
> This looks quite interesting for the types of simple apps I'm building 
> right now. However, I have discovered a couple of bugs. I don't see any way 
> to report them on bitbucket. 
>
> Are you taking bug reports, and if so, what is the best way to communicate 
> them?
> Are you taking outside pull requests for bug fixes?
>
> Thanks for the great work,
>
>
> On Thursday, September 6, 2018 at 12:07:41 AM UTC-4, Robert Johnstone 
> wrote:
>>
>> This is an initial announcement of goey, a package for declarative, 
>> cross-platform GUIs.  The range of controls, their supported properties and 
>> events, should roughly match what is available in HTML.  However, 
>> properties and events may be limited to support portability.  Additionally, 
>> styling of the controls will be limited, with the look of controls matching 
>> the native platform.
>>
>> A minimal example of a complete application can be found at 
>> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>>
>> * README:  https://bitbucket.org/rj/goey/src/default/README.md
>> * godoc: https://godoc.org/bitbucket.org/rj/goey
>>
>> Feedback welcome.
>>
>>

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

Re: [go-nuts] Existing code for order-preserving concurrent work queue?

[robert engels]

I think that level of imbalance is the design thought behind “work stealing 
queues” - which is what Go schedulers uses.. no ?

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

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

Re: [go-nuts] Re: Existing code for order-preserving concurrent work queue?

[Michael Jones]

Agree. I’ve never had that level of imbalance but yes.

On Thu, Jan 31, 2019 at 4:06 AM roger peppe  wrote:

> On Thu, 31 Jan 2019 at 00:06, Michael Jones 
> wrote:
>
>> note that my code sidesteps this problem generally
>>
>
> I'm not sure that that's true. Although your code mitigates the problem
> somewhat,
> it's still possible for a one slow worker to block the others. You've
> added 512*NumCPU/2
> buffer slots, but in general it's not possible to order results and
> provide avoid unnecessary
> blocking without having N buffer slots. In your code, assume 4 CPUs and
> that work items 0
> and 2 take 1s and all other work items take 1ms. If we've got 5000 items
> in total,
> the total time taken will be 2.002498s instead of the ideal time
> (~1s+2499µs).
>
> https://play.golang.org/p/5Ty6pgpmZ0w
>
> Here's a kind of hybrid approach. It still serializes, but it makes as
> good a use of the buffer
> space as it can - it won't block until a slow item is at least bufSize
> items behind the
> most recently processed item:
>
> https://play.golang.org/p/PP9NSJuLeEK
>
>
>> On Wed, Jan 30, 2019 at 3:48 PM roger peppe  wrote:
>>
>>> On Wed, 30 Jan 2019 at 20:07, 'Bryan Mills' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
 The code to sequence the results using a channel is not much more
 verbose.

 That not only avoids the library dependency, but also makes the peak
 memory consumption for the results O(runtime.NumCPU()), instead of O(N)
 with the number of tasks, and allows the output to be streamed instead of
 buffered to a slice.

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

>>>
>>> Nice! In practice though, I've usually found that I do want to keep the
>>> results around or I don't care about the order at all, so the parallel
>>> package works OK.
>>>
>>> I'd point out one down side to the sequencing approach - one very slow
>>> work item can block the others. For example, NProc is 4, the first item
>>> takes 200 milliseconds to process and all the others take 1 millisecond,
>>> then the first 4 workers have started, none more will be started until the
>>> first has, so the overall time will be quite a bit longer (249ms) than if
>>> they were all allowed to proceed irrespective of order (200ms).
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com *
>>
> --

*Michael T. jonesmichael.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.

Re: [go-nuts] Re: Memory usages

[Michael Jones]

Yes. Now you can answer this question when the next person asks.

On Wed, Jan 30, 2019 at 10:56 PM 伊藤和也  wrote:

> OK, I want to make it clearer.
>
> Whether constants are untyped or typed, constants are treated at compile
> time and originary there is no idea of how much memory constants take but
> there is the idea of how much memory variables take so I should just focus
> on how much memory variables take at runtime.
> That's why for the examples below, the total memory usages are both "4"
> bytes respectably at runtime. Is it correct?
>
>> 1. var num int32 = 100
>>  |
>> 4 bytes
>
> 2. var num int32 = int32(100)
>>  |
>> 4 bytes
>
>
>
> 2019年1月31日木曜日 9時05分32秒 UTC+9 伊藤和也:
>
>> An interger constant is "int" type and takes "8" bytes memory on 64-bit
>> system.
>>
>> fmt.Println(unsafe.Sizeof(100)) // 8
>>> fmt.Println(reflect.TypeOf(100)) // int
>>
>>
>> and an "int32" type value takes "4" bytes.
>>
>> var num int32
>>> fmt.Println(unsafe.Sizeof(num)) // 4
>>
>>
>> So in this case below, Is the memory usage "12" bytes in total? (Question
>> 1)
>>
>> var num int32 = 100
>>>  |  |
>>> 4 bytes  +  8 bytes = 12 bytes
>>
>>
>> and in this case below, Is the memory usage "16" bytes in total?
>> (Question 2)
>> because the integer constant "100" is "8" bytes first then it's converted
>> to "int32" which is "4" bytes.
>>
>> var num int32 = int32(100)
>>>  | | |
>>>4 bytes + 4 bytes + 8 bytes = 16 bytes
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.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] Support for >31 bit sub-identifier in x509 certificate OIDs

[adamyoung600]

Referring to the fix put in place for this issue:


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

I have a user of our product (parts of it written in Go) who would like to 
use certificates supplied by their IT department.  These certificates have 
a field containing their internal CertificatePolicyID which contains an oid 
subidentifer which would need 36 bits to represent.  Due to the restriction 
from the above linked issue GO doesn't support larger than 31 bit 
sub-identifiers. 

I could not find an open issue but is it possible to find out if support 
for larger oid sub-identifiers will ever be considered?


Thanks,
Adam


-- 
You received this message because you are subscribed to the Google 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: Existing code for order-preserving concurrent work queue?

[roger peppe]

On Thu, 31 Jan 2019 at 00:06, Michael Jones  wrote:

> note that my code sidesteps this problem generally
>

I'm not sure that that's true. Although your code mitigates the problem
somewhat,
it's still possible for a one slow worker to block the others. You've
added 512*NumCPU/2
buffer slots, but in general it's not possible to order results and provide
avoid unnecessary
blocking without having N buffer slots. In your code, assume 4 CPUs and
that work items 0
and 2 take 1s and all other work items take 1ms. If we've got 5000 items in
total,
the total time taken will be 2.002498s instead of the ideal time
(~1s+2499µs).

https://play.golang.org/p/5Ty6pgpmZ0w

Here's a kind of hybrid approach. It still serializes, but it makes as good
a use of the buffer
space as it can - it won't block until a slow item is at least bufSize
items behind the
most recently processed item:

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


> On Wed, Jan 30, 2019 at 3:48 PM roger peppe  wrote:
>
>> On Wed, 30 Jan 2019 at 20:07, 'Bryan Mills' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> The code to sequence the results using a channel is not much more
>>> verbose.
>>>
>>> That not only avoids the library dependency, but also makes the peak
>>> memory consumption for the results O(runtime.NumCPU()), instead of O(N)
>>> with the number of tasks, and allows the output to be streamed instead of
>>> buffered to a slice.
>>>
>>> https://play.golang.org/p/zkBjxlcvESe
>>>
>>
>> Nice! In practice though, I've usually found that I do want to keep the
>> results around or I don't care about the order at all, so the parallel
>> package works OK.
>>
>> I'd point out one down side to the sequencing approach - one very slow
>> work item can block the others. For example, NProc is 4, the first item
>> takes 200 milliseconds to process and all the others take 1 millisecond,
>> then the first 4 workers have started, none more will be started until the
>> first has, so the overall time will be quite a bit longer (249ms) than if
>> they were all allowed to proceed irrespective of order (200ms).
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> *Michael T. jonesmichael.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.

Re: [go-nuts] database/sql: NextResultSet API always return false

[Lutz Horn]

Then why this method is not works as expected using
github.com/go-sql-driver/mysql for MySQL.


It would have helped me if you'd have mentioned MySQL in your question. 
Your question was incomplete. Please take alook at


http://www.catb.org/esr/faqs/smart-questions.html


Take a look at this: https://play.golang.org/p/tCLKxiXPZ5e


I can reproduce this problem for MySQL. Sadly I don't find any issue 
about NextResultSet always returning false:


https://github.com/go-sql-driver/mysql/search?q=NextResultSet=Issues

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.

Re: [go-nuts] database/sql: NextResultSet API always return false

[sagar puneria]

Then why this method is not works as expected using 
github.com/go-sql-driver/mysql for MySQL. 
Take a look at this: https://play.golang.org/p/tCLKxiXPZ5e

On Thursday, January 31, 2019 at 1:37:01 PM UTC+5:30, Lutz Horn wrote:
>
> Hi, 
>
> > I just want to know in which case NextResultSet 
> >  return true? 
>
> This method works as expected using github.com/lib/pq for PostgreSQL. 
> Take a lookt at this: 
>
> https://gist.github.com/lutzhorn/1aa7de538d1edd0b3904799b5bb972fd 
>
> The output is: 
>
> {'\x01' "cmelling0"} 
> {'\x02' "mbarkess1"} 
> {'\x03' "ssquibb2"} 
> {'\x04' "akirk3"} 
> {'\x05' "kelcomb4"} 
> {'\x06' "lcoldbathe5"} 
> {'\a' "ibutcher6"} 
> {'\b' "wdarnbrook7"} 
> {'\t' "bcoraini8"} 
> {'\n' "wplews9"} 
>
>
> 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.

Re: [go-nuts] database/sql: NextResultSet API always return false

[sagar puneria]

Then why this method is works as expected using 
github.com/go-sql-driver/mysql for MySQL. 
Take a look at this: https://play.golang.org/p/tCLKxiXPZ5e

On Thursday, January 31, 2019 at 1:37:01 PM UTC+5:30, Lutz Horn wrote:
>
> Hi, 
>
> > I just want to know in which case NextResultSet 
> >  return true? 
>
> This method works as expected using github.com/lib/pq for PostgreSQL. 
> Take a lookt at this: 
>
> https://gist.github.com/lutzhorn/1aa7de538d1edd0b3904799b5bb972fd 
>
> The output is: 
>
> {'\x01' "cmelling0"} 
> {'\x02' "mbarkess1"} 
> {'\x03' "ssquibb2"} 
> {'\x04' "akirk3"} 
> {'\x05' "kelcomb4"} 
> {'\x06' "lcoldbathe5"} 
> {'\a' "ibutcher6"} 
> {'\b' "wdarnbrook7"} 
> {'\t' "bcoraini8"} 
> {'\n' "wplews9"} 
>
>
> 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.

Re: [go-nuts] How to do for inserting input data(http request post method) into postgresql database

[Lutz Horn]

I used  net/http package to build up the http server with golang. 
Also,I make the simple Html page for front end . But I don't know how

to do for inserting input data(http request post method) into
postgresql database ? Any one could provide the sample code ?


This may not be the best Go code ever written but it does what you ask 
for: read a HTTP POST request body and write it into a PostgreSQL database:


Handle the HTTP POST request JSON body:

https://github.com/lutzhorn/shortenyoururl-go/blob/ece65aa0bc7b4bbd12d4b3daf039e762b16728f9/handler.go#L135

Insert the scanned body into the database:

https://github.com/lutzhorn/shortenyoururl-go/blob/ece65aa0bc7b4bbd12d4b3daf039e762b16728f9/handler.go#L179

https://github.com/lutzhorn/shortenyoururl-go/blob/ece65aa0bc7b4bbd12d4b3daf039e762b16728f9/db.go#L95

Regards

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.

Re: [go-nuts] database/sql: NextResultSet API always return false

[Lutz Horn]

Hi,


I just want to know in which case NextResultSet
 return true?


This method works as expected using github.com/lib/pq for PostgreSQL. 
Take a lookt at this:


https://gist.github.com/lutzhorn/1aa7de538d1edd0b3904799b5bb972fd

The output is:

{'\x01' "cmelling0"}
{'\x02' "mbarkess1"}
{'\x03' "ssquibb2"}
{'\x04' "akirk3"}
{'\x05' "kelcomb4"}
{'\x06' "lcoldbathe5"}
{'\a' "ibutcher6"}
{'\b' "wdarnbrook7"}
{'\t' "bcoraini8"}
{'\n' "wplews9"}


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.