Re: [go-nuts] [ANN] fixed point math library

Which reminds me...these kinds of name changes deserve a thread/list in the Go2 proposals On Sat, Dec 1, 2018 at 12:17 AM Anthony Martin wrote: > Nigel Tao once said: > > Well, there's already context.Context, hash.Hash, image.Image and > > time.Time in the standard library. > > All of which

[go-nuts] Re: pointer dereference optimization in loops

Mark Volkmann once said: > Suppose myPtr is a pointer and I write code like this: > > for _, v := range values { > fmt.Printf("%v %v\n", *myPtr, v) > } > > Will the Go compiler optimize the pointer dereference so it doesn't happen > in every loop iteration? If not, is it common practice to do

Re: [go-nuts] [ANN] fixed point math library

Nigel Tao once said: > Well, there's already context.Context, hash.Hash, image.Image and > time.Time in the standard library. All of which are not great. Better names are context.Frame, hash.Function, raster.Image, and time.Instant. Anthony -- You received this message because you are

Re: [go-nuts] [ANN] fixed point math library

Very nice. On Sat, 2018-12-01 at 00:16 -0800, Anthony Martin wrote: > Nigel Tao once said: > > > > Well, there's already context.Context, hash.Hash, image.Image and > > time.Time in the standard library. > All of which are not great. Better names are context.Frame, > hash.Function,

Re: [go-nuts] Package Stutter

I know everyone hates it when I reference java but it has had dot imports at the package level since day one. I won’t repeat why that matters. It’s never been a problem. I don’t think I ever heard someone complain it was a problem in working in Java, why is it such a problem in Go? I’m

Re: [go-nuts] Package Stutter

Quoting robert engels (2018-12-02 00:59:31) >Granted, their package structure seems poor in my opinion, but you >can't talk bad about k8s. Of course you don't lose anything by getting rid of the package names if the package structure doesn't make any sense in the first place. >And

Re: [go-nuts] Package Stutter

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

Re: [go-nuts] Package Stutter

I think context.Context is fine, it’s weird though I’ll admit. The way to fix it though it just to use dot imports, and encourage it! The only time dot imports don’t work is when there isn’t package stutter. Seems like a no brainer and you get the best of both worlds. You have similar

Re: [go-nuts] Package Stutter

Quoting Robert Engels (2018-12-01 22:25:06) > The way to fix it though it just to use dot imports, and encourage it! > The only time dot imports don't work is when there isn't package > stutter. Seems like a no brainer and you get the best of both worlds. My experience in every language I've

Re: [go-nuts] Package Stutter

I was thinking the similarly, which is why I thought about the List case. In Java, however you get there, it is just referred to as List In Go, it is going to be list.List And in a competing implementation it is going to be container.List or whatever package the author came up with. That’s a

Re: [go-nuts] Package Stutter

Based on your explanation, my original understanding of the semantics were correct. This: > import java.util.Collections; ..is not a dot import -- a dot import makes visible every (exported) identifier in the package. This just exposes the one identifier -- Collections. I don't have a problem

Re: [go-nuts] Rethink possibility to make circular imports

Anecdote: A (large) Java project I worked on ran into trouble with cyclic dependencies so often, that they started introducing conventions like "classes under directory X are not allowed to import classes under directory Y (but vice-versa)", effectively emulating Go's prohibition of cyclic imports

Re: [go-nuts] Rethink possibility to make circular imports

I find the same, but eventually I come up with a way to clarify. Just *Not Real Soon* (;-)) >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [go-nuts] Package Stutter

For what it's worth, we considered various ways to shorten context.Context before releasing it as open source. The obvious choice would be context.C, but I was concerned this would encourage people to name their context variables c, which conflicts with the common short name for channel variables.

Re: [go-nuts] Package Stutter

And when reading through code no Java developer goes, hmmm I wonder what a List is - since List in idiomatic use is the List interface from java.util.List. Could it be another List type, possibly the java.awt.List, but that’s only used in awt related code, and if it’s truly a different List

Re: [go-nuts] Package Stutter

I think it is especially problematic for python because: import * + type inference + dynamic language = hell in my book. > On Dec 2, 2018, at 12:26 AM, Ian Denhardt wrote: > > Quoting robert engels (2018-12-02 00:59:31) > >> Granted, their package structure seems poor in my opinion, but

Re: [go-nuts] Package Stutter

The ‘static import’ allows you to refer to things like this: import static java.util.Collections.sort; public class ScratchTest { public static void main(String[] args) { java.util.List list = sort(java.util.Collections.singletonList(new Object()); } } but typically, the static

Re: [go-nuts] Package Stutter

Quoting robert engels (2018-12-02 01:43:45) > import * + type inference + dynamic language = hell Can't have type inference without types, so it's just the dynamic bit, but I basically agree -- combined with the fact that you can do nonsense black magic with the import machinery at runtime in

Re: [go-nuts] Package Stutter

The .* doesn’t mean what you think it does - that just means all of the classes in the package. It is no different than listing them each. When you use import java.util.Collections; import java.util.List; You are actually doing a dot import, so you can in the code just refer to it as so List

Re: [go-nuts] Package Stutter

In both Java and C++ (statically compiled languages), Google's style guides prohibit "wildcard"-style imports of an entire library: https://google.github.io/styleguide/javaguide.html#s3.3.1-wildcard-imports https://google.github.io/styleguide/cppguide.html#Namespaces I believe the restriction is

Re: [go-nuts] Package Stutter

Quoting Robert Engels (2018-12-02 00:19:40) > I know everyone hates it when I reference java but it has had dot > importsat the package level since day one. I won’t repeat why that > matters. It’s never been a problem. > > I don’t think I ever heard someone complain it was a problem in > working

Re: [go-nuts] Package Stutter

Quoting robert engels (2018-12-02 01:55:17) > added to Go, but I am not sure if the package has a few related types > (which it should IMO) it is any better than > > import . “package” This also exposes stand-alone functions, constants etc. which doesn't come up in Java. I think the stutter

Re: [go-nuts] Package Stutter

As some supporting evidence, here is a method signature in k8s: func matches(p abac.Policy, a authorizer.Attributes) bool { The interesting aspect is that this method is in package abac, except it is in pkg/auth/authorizer/abac and the one being used in the method pkg/apis/abac Do you really

Re: [go-nuts] [ANN] fixed point math library

I disagree with a few of those, but the simplest example is image. There still needs to be an image.Image interface for methods common to all image types. Then sub packages for raster and vector (others?) There are too many different image types so you end up a multitude of packages and since

Re: [go-nuts] [ANN] fixed point math library

I need to do a thorough summary, but as an example of things that could usefully change (perhaps) for improved coherence and excellence in Go2 through naming and simple rewrites, consider the image package. 1. The name of the package (fine always it seem, but in some cases maybe a change would

Re: [go-nuts] [ANN] fixed point math library

hash.Function? Then you need print.Function. So soon enough there will be a 1000 interfaces named Function that have nothing to do with hashing or printing because everything can be decomposed that way. context.Frame? Now you’re just being silly. You might as well use context.Instance or even

Re: [go-nuts] [ANN] fixed point math library

And while we’re at it, take a closer look at the hash package https://golang.org/pkg/hash/#Hash Especially the example and the doc surrounding it. Why doesn’t Hash “extend” the binary marshall interfaces? Why the need to cast if the documentation says it does? There are a lot of low hanging

Re: [go-nuts] [ANN] fixed point math library

And let’s keep going, the sha256 package handles sha256 and sha224 ? Huh? And the NewX return hash.Hash rather than the concrete type - which would be fine except for the implicit Marshall interfaces. If they returned the concrete type I could have my own interface HashWithMarshall it could be

[go-nuts] Package Stutter

In another thread, it has been brought up that things like time.Time are no good. But this format is pervasive. Even newer packages like context.Context. It seems to have been this way for a long time. It there some reasoned paper on why this is now so frowned upon? -- You received this

Re: [go-nuts] [ANN] fixed point math library

On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak wrote: > Very nice. Indeed . -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] [ANN] fixed point math library

This is a problem with it seems more than a few in this community. Someone makes a criticism of an idea, backs it up, and is treated in a childish manner because it doesn’t go along with dominate opinions of the controllers of the group think. Not good IMO. > On Dec 1, 2018, at 7:48 AM, Jan

Re: [go-nuts] [ANN] fixed point math library

Sorry, more than few is too many. Few is more appropriate. And before this goes farther. It was a thread I started to announce a project some might find useful or interesting. It was hijacked by the powers and turned into something else. It wasn’t the point, nor what I wanted. > On Dec 1,

Re: [go-nuts] [ANN] fixed point math library

A hash function is a mathematical construction. A raster image is a type of graphical representation. A time instant is a single point in a duration. All of these are clear as can be. I'll give you "context frame". It is a bit wonky. A better phrase is out there somewhere. Scope, environment,

Re: [go-nuts] how to build golang program with a lower kernel requirement?

You are somehow confused. The kernel version requirement of some particular glibc version is not relevant. There is no problem. It works. See https://github.com/golang/go/wiki/MinimumRequirements for kernel version requirements. Hope this helps, Janne Snabb sn...@epipe.com On 30/11/2018

Re: [go-nuts] [ANN] fixed point math library

I can see why you're feeling that. My sense is that what causes flare-ups is when people (universally rather than just here) get the feeling that the discussion is becoming personal rather than technical. Go is lots of people's work / tool / job / fun / etc., so passions may be strong, but I've

Re: [go-nuts] [ANN] fixed point math library

I'll also add that personally I saw a lot of "change this" commentary with rather little "thank you." That was not in the best spirit of what (at at least I think) it should be. It's always good to act on ideas, build solutions, and share results. It would be great if everyone always started with

Re: [go-nuts] Package Stutter

In the cases of time and context, the stutters appear in a primary type that is important to the package, but rarely appears directly in normal API usage. E.g., time.Now(), context.Background(). Stutter is to be avoided. The package name can provide context. But stutter is preferred to, e.g.

Re: [go-nuts] Package Stutter

On Sat, Dec 1, 2018 at 9:53 AM Robert Engels wrote: > > That was my point. The earliest practitioners and language designers used the > construct extensively but now others claim it is not the way. I find it hard > to believe that in testing the original Go design the creators didn’t think >

Re: [go-nuts] Package Stutter

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

Re: [go-nuts] Package Stutter

I agree. You need to understand the expected usage patterns (and possibly other external and internal constraints) before you can claim that any design “needs change”. > On Dec 1, 2018, at 12:18 PM, Bakul Shah wrote: > > Reducing stutter.Stutter is a good thing. But coming up with meaningful

[go-nuts] convert *byte to []byte

Hi: I am using swig wrap a c++ module , the generated go code is like this: type MediaFrame interface { GetLength() uint GetData() (*byte) } I want to convert the *byte to []byte, How to do this? -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] [ANN] fixed point math library

Please stay polite, and please follow the code of conduct (https://golang.org/conduct). Thanks. 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

Re: [go-nuts] Package Stutter

That was my point. The earliest practitioners and language designers used the construct extensively but now others claim it is not the way. I find it hard to believe that in testing the original Go design the creators didn’t think about this - which means they decided it was fine. So why the

Re: [go-nuts] Package Stutter

I can understand that and it seems reasonable but if I’m writing a new Ring “class” and it supports both a standard and a concurrent version, I’m probably not going to create two packages. I would create one package named ring and have NewRing and NewSyncRing. Which is what I and I think you

[go-nuts] convert *byte to []byte

C.GoBytes -- You received this message because you are subscribed 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] GoAWK: an AWK interpreter written in Go

> I wonder if it makes sense, to expose more of the interpreter to go. > E.g.: register a user function or add an action written in go. > I had thought about this before, but your comment made me want to try it. It wasn't actually that hard, so I've added backwards-compatible support for this now

[go-nuts] Re: [ANN] Koazee a library inspired by functional programming and lazy evaluation that takes the hassle out of working with arrays

Last weeks I've been working on improving performance in Koazee. I put in practice all your advices and even though I don't have a second release ready, I wrote an article to share my experience trying to improve performance

Re: [go-nuts] The most performant deque of all time?

FYI, we just released deque [v1.0.2]( https://github.com/ef-ds/deque/blob/master/CHANGELOG.md). Due to the amazing contributions of Roger Peppe , deque is not only faster now, but also more efficient! Roger is such an incredible coder! Also want to say many thanks for