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 database-y
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 th
ср, 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: v.tols...@se
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 u
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,
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 tha
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 dif
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 HTTP
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 versio
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 k
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
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
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 proposa
> 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 gist
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
mistak
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 exampl
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 passin
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 stri
* 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
> suppor
@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
infinit
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 desig
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 in
Hi,
I know it's been a year since this thread was mentioned but I thought I
would add an update for anyone finding this topic.
I wanted to try using shiny as it's got some great foundations and is well
thought out. Unfortunately it's a few steps short of being really useful.
Looking at the demo
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 a
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 manua
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 25
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 wrote:
27 matches
Mail list logo