On Thu, 25 Oct 2018, 12:52 am Axel Wagner,
wrote:
> On Thu, Oct 25, 2018 at 12:39 AM roger peppe wrote:
>
>> I understand this argument. By putting some smarts into the compiler, we
>> would hope that we can see benefits not just in our generated generic code,
>> but also in other code that
Never mind I found the ForkJoinPool.
> On Oct 25, 2018, at 6:22 AM, Robert Engels wrote:
>
> I see the pattern used in ErrGroup pipeline a lot:
>
> c := make(chan result) const numDigesters = 20 for i := 0; i < numDigesters;
> i++ {
> which leads me to question the effectiveness of this
I see the pattern used in ErrGroup pipeline a lot:
c := make(chan result) const numDigesters = 20 for i := 0; i < numDigesters;
i++ {
which leads me to question the effectiveness of this design. Sure, you bound
the number of routines, and this should probably be something like cores * 2,
but
@Sebastien
The biggest difference is my package makes guarantees that when a bundle is
garbage collected the context and thus child goroutines
are cancelled. This lets you be more creative having shared ownership of
groups of goroutines, e.g. a collection of goroutines producing a lazy
No need. I was just getting very confused trying to follow.
> On Oct 25, 2018, at 10:59 AM, jake6...@gmail.com wrote:
>
> Yes. I was completely mistaken in my post. Apologies.
>
>> On Wednesday, October 24, 2018 at 12:14:36 PM UTC-4, robert engels wrote:
>> I quote
>>
>> So in the OP's
Oops. Please ignore my entire post. Misunderstood completely.
On Wednesday, October 24, 2018 at 11:55:18 AM UTC-4, Jake Montgomery wrote:
>
> That is correct. The relevant part of
> https://golang.org/ref/spec#Passing_arguments_to_..._parameters is where
> it says: " respective parameter
In my defense, neither A() nor B() complies in the actual example given. If
you comment out A() you will see that B() then fails to compile.
If B() is fixed by replacing "i = append(i, s)" with "i = append(i, sa)",
then it succeeds. I believe that is due to the clause I referenced in my
> On Oct 25, 2018, at 6:45 AM, Marvin Renich wrote:
>
> The most powerful feature of the contracts described in the original
> design draft is the ability to describe interactions between two types
> in a type specification. Your proposal doesn't seem to allow this.
See the section of my
On Wednesday, 24 October 2018 18:52:27 UTC+2, Michael Jones wrote:
>
> https://en.wikipedia.org/wiki/Q_(number_format) says it all.
>
> you can use fixed point all the way...just shift after multiplies and
> before divides and use double-width (int32) or wider math.
>
>
Yes, that's close enough
Yes. I was completely mistaken in my post. Apologies.
On Wednesday, October 24, 2018 at 12:14:36 PM UTC-4, robert engels wrote:
>
> I quote
>
> So in the OP's example https://play.golang.org/p/59bpr8TCIge, the
> function A() is assigning a []string to the variadic ...[]interface{}.
> Since
On Thu, Oct 25, 2018 at 10:32 AM Andy Balholm wrote:
>
>
>
> On Oct 25, 2018, at 6:45 AM, Marvin Renich wrote:
>
> The most powerful feature of the contracts described in the original
> design draft is the ability to describe interactions between two types
> in a type specification. Your
ср, 24 окт. 2018 г. в 19:52, Michael Jones :
>
> https://en.wikipedia.org/wiki/Q_(number_format) says it all.
>
> you can use fixed point all the way...just shift after multiplies and before
> divides and use double-width (int32) or wider math.
>
Thanks!
--
Vasiliy Tolstov,
e-mail:
On Thu, Oct 25, 2018 at 1:53 PM Eric S. Raymond wrote:
>
> robert engels :
> > Wouldn’t you normally pass a consumer or collector function into the
> > interator code? Then you only write the iterator once, and it is hidden.
>
> I'll look into that approach. There might be a readability issue
* Andy Balholm [181024 17:52]:
> What I’m doing with structural contracts is basically the same as what
> you’re doing with struct and interface types as contracts, except that
> (I hope) the syntax is a little clearer.
>
> I added the support for operators basically to avoid having the
>
Wouldn’t you normally pass a consumer or collector function into the interator
code? Then you only write the iterator once, and it is hidden.
Similar to how the sync.Map.Range() works.
Barring that, I don’t see how
for(i:=c.Iterator();i.HasNext();) {
v := i.Next()
}
is that much more
Guilty. ;-)
It's also more complicated because of the desire for saturating arithmetic.
On Thu, Oct 25, 2018 at 9:57 AM Scott Cotton wrote:
>
>
> On Wednesday, 24 October 2018 18:52:27 UTC+2, Michael Jones wrote:
>>
>> https://en.wikipedia.org/wiki/Q_(number_format) says it all.
>>
>> you can
Jan Mercl <0xj...@gmail.com>:
> The 'obvious' way is not something I'd consider. The 'concise' way works
> today, provided iterator function returns a slice or a map.
Yes, but returning a slice (eager evaluation) is exactly what I want to avoid.
The context: the repository where my Python
Does not look like a valid HEAD request. It should be "HEAD / HTTP/1.1"
-Agniva
On Friday, 26 October 2018 00:15:14 UTC+5:30, Swapnil Mhatre wrote:
>
> Hi,
>
> I wanted to check on the forum first before filing an issue. Please see
> below for the issue I am seeing.
> I used a valid POSTMAN
Hi,
I wanted to check on the forum first before filing an issue. Please see
below for the issue I am seeing.
I used a valid POSTMAN HTTP HEAD request message for my test.
### What version of Go are you using (`go version`)?
go 1.11
### Does this issue reproduce with the latest release?
Don't
robert engels :
> Wouldn’t you normally pass a consumer or collector function into the
> interator code? Then you only write the iterator once, and it is hidden.
I'll look into that approach. There might be a readability issue there.
> Similar to how the sync.Map.Range() works.
>
> Barring
Axel Wagner :
> So, how many such loops are there?
In my code? 82, for a first approximation. there might be some I'm missing.
--
http://www.catb.org/~esr/;>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site
The design has been used in Java for many, many, years… pretty sure most
developers understand it. In fact, before Java had generics and the Iterable
interface it was the only game in town if you wanted type safety - and the Go
code is even more concise do to type inference.
> On Oct 25, 2018,
On Fri, Oct 26, 2018 at 6:04 AM robert engels wrote:
> Barring that, I don’t see how
>
> for(i:=c.Iterator();i.HasNext();) {
> v := i.Next()
> }
>
> is that much more difficult to use
Yes, an iterator with a Next method (possibly with another name) is
the idiomatic way to present
A mini library I came up with, let me know what you think:
https://github.com/andrewchambers/bundle
Introduces the concept of a bundle of goroutines.
- All goroutines part of a bundle share a context.
- The context is cancelled automatically when the bundle is garbage
collected.
- You can
Hi Andrew,
On Thu, Oct 25, 2018 at 11:56 AM wrote:
> A mini library I came up with, let me know what you think:
>
> https://github.com/andrewchambers/bundle
>
> Introduces the concept of a bundle of goroutines.
>
> - All goroutines part of a bundle share a context.
> - The context is cancelled
Sure: https://play.golang.org/p/W_ruqI22Vhv
Seems a fairly straight-forward transformation to me - and again easy to
devirtualize.
On Thu, Oct 25, 2018 at 8:56 AM roger peppe wrote:
>
> On Thu, 25 Oct 2018, 12:52 am Axel Wagner,
> wrote:
>
>> On Thu, Oct 25, 2018 at 12:39 AM roger peppe
Sorry, should've added what I consider the source:
https://play.golang.org/p/3_um7p3IxwK
On Thu, Oct 25, 2018 at 10:09 AM Axel Wagner
wrote:
> Sure: https://play.golang.org/p/W_ruqI22Vhv
> Seems a fairly straight-forward transformation to me - and again easy to
> devirtualize.
>
> On Thu, Oct
27 matches
Mail list logo
