[go-nuts] named go routines?

Hi, I recently started developing more complex concurrent Go applications. Using the debugger is very difficult - since when looking for a particular routine, the list only shows the top level method - which is usually a runtime park. Couldn't we have a syntax like: go name_exp fun() {...}()

[go-nuts] Re: Link: Getting specific about generics

I do like using interfaces only, and having the language declare some built-in ones and automatically map them to the operators. A problem is that for consistency they should go both ways... and then you end up with operator overloading which I've never been a fan of because people use it to wr

Re: [go-nuts] Re: What am I missing here? FYI, I'm completely new to golang xD

The real gotcha is this though, var x int if blah { x,err := somefunc() } Probably does not do what you think as the value from somefunc() will not be available outside of the if statement... This is a poor design choice by golang IMO but it is what it is... > On Sep 4, 2018, at 9:22 AM, Na

Re: [go-nuts] Re: What am I missing here? FYI, I'm completely new to golang xD

handling in go... but that’s another topic. :) Sent from my iPhone > On Sep 4, 2018, at 10:45 AM, Michael Jones wrote: > > Block scope is a superpower since Algol. > >> On Tue, Sep 4, 2018 at 7:29 AM Robert Engels wrote: >> The real gotcha is this though, >> >

[go-nuts] Go concurrency performance

Hi, I posted this to golang-dev, and the consensus seems to be this is a better forum to address the issue? Anyway, you can review the project https://github.com/robaho/go-concurrency-test The readme.md details the experiment. It does some analysis of the Go concurrency primitives, in the co

Re: [go-nuts] Re: Go concurrency performance

Am Donnerstag, 6. September 2018 15:00:18 UTC+2 schrieb Robert Engels: > Hi, > > I posted this to golang-dev, and the consensus seems to be this is a better > forum to address the issue? > > Anyway, you can review the project > https://github.com/robaho/go-concurrency-t

Re: [go-nuts] Re: Generics as builtin typeclasses

I think the 90% rule applies… if we can have a simple solution that covers 90%, rather than a complex one to cover 100%, go with the simple. There are always trade-offs in development - having simple, easy to understand tools always wins out IMO - because greater adoption and usage is key. > On

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

I might be able to do it if there was a “porting guide” that describes what needs to be - at least in general terms - rather than just looking at the existing code and making a guess > On Sep 7, 2018, at 10:01 AM, Robert Johnstone wrote: > > Hello, > > I would be very happy to support macOS,

Re: [go-nuts] Re: Generics as builtin typeclasses

For the math operator, since Go already doesn’t do automatic numeric conversions, all of the operators are almost trivially implemented as methods, e.g. operator + is pseudo generic interface - not really required type PlusOperator interface { Plus(A) A } and given type MyStruct struc

Re: [go-nuts] Operator Overloading Implies Generics?

I think the lack of method overload is a poor choice. A simple review of the stdlib shows a lot of XFromInt XFromUnit and that is workable, but when you have complex structs as parameters, then the naming because really long… and the fact that you don’t have file level hiding, means even for loc

Re: [go-nuts] Re: Generics as builtin typeclasses

Which is why I believe this can happen with existing interfaces and compiler magic. (along with my other proposal regarding carrying the concrete type in slices). You can do operator overloading and type conversion with interfaces. (although not a big fan of operator overloading…) Method overl

Re: [go-nuts] Operator Overloading Implies Generics?

rts was able to auto disambiguate in just these cases. > > > > On Sun, Sep 9, 2018 at 6:43 AM robert engels <mailto:reng...@ix.netcom.com>> wrote: > I think the lack of method overload is a poor choice. A simple review of the > stdlib shows a lot of XFromInt XFromUnit an

Re: [go-nuts] Operator Overloading Implies Generics?

even with Java it is not ambiguous, as the JLS states it will use the most specific method possible, so the single parameter one when only a single parameter is passed. > On Sep 9, 2018, at 10:37 AM, Sam Whited wrote: > > > > On September 9, 2018 1:43:09 PM UTC, robert e

Re: [go-nuts] Re: Generics as builtin typeclasses

2018, at 1:52 PM, Jonathan Amsterdam wrote: > > > > On Saturday, September 8, 2018 at 11:58:46 PM UTC-4, Robert Engels wrote: > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as >

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

a minimal example of showing a window. > > 4) At that point, you should have most of the difficult work done. The next > steps will be to port over the controls one-by-one, but the infrastructure > will be in place, so that work con be done a small piece at a time. > >

Re: [go-nuts] [ANN] goey - Declarative, cross-platform GUIs

“wouldn’t be that hard" > On Sep 10, 2018, at 1:24 PM, robert engels wrote: > > I wonder about the design, and how it will work. Since it uses the native > components behind the scene, you will get great fidelity but the layout can > be very difficult to accomplish. >

Re: [go-nuts] "Craftsman's" Go Generics proposal

I would argue that is not generics code - the fact that you are type checking in the implementation is a problem, and replicating the logic for “each type”. You would probably have simpler code just define an interface Value(), and a ComplexValue() and two methods… But even then, you need my pro

Re: [go-nuts] "Craftsman's" Go Generics proposal

zarnecki wrote: > > On Mon, 10 Sep 2018 15:31:41 -0500 > robert engels wrote: > >> You would probably have simpler code just define an interface Value(), and >> a ComplexValue() and two methods… > ...and implement it on any single type I wanna sum? No, thanks. I

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > wrote: > > [golang-nuts to CC, golang-dev to BCC] > > On Mon, Sep 10, 2018 at 5:33 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > In the entire codebase of Docker I could f

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

I, and suggest others, look at real world applications to see how the proposal would work/benefit. I appreciate the feedback. > On Sep 11, 2018, at 10:50 AM, 'Axel Wagner' via golang-nuts > wrote: > >> On Tue, Sep 11, 2018 at 5:28 PM robert engels wrote: >>

Re: [go-nuts] Generics - Why contracts?

As I’ve said elsewhere, a SIMPLE to use and understand solution that covers 90% is better than a complex one to cover 100% IMO, and fits in well with the rest of Go design. Go leaves out a lot - intentionally - and it’s a good choice. > On Sep 11, 2018, at 11:22 AM, alan.f...@gmail.com wrote: >

Re: [go-nuts] Golang equivalent of Python's context manager

I think it would be problematic, as the callee signature is limited - func() error - and with lack of method overloading you will need a lot of With methods… > On Sep 12, 2018, at 6:58 AM, Mirko Friedenhagen wrote: > > Hello, > > in Python I may define context managers which do stuff befo

Re: [go-nuts] Go memory usage inside containers

I don’t think Java needs visibility into the max memory, as you need to set it via args (-Xmx) if you want a max - otherwise it will just keep allocation as it needs it - if an allocation from the OS fails, it will attempt a final GC to see if it can get more room, and if not, OOME. The Runtime

Re: [go-nuts] Golang equivalent of Python's context manager

of function f. See the main method… I am assuming this is attempting to be a general facility - and thus the signature of f will vary. > On Sep 12, 2018, at 7:18 AM, Sebastien Binet wrote: > > > > On Wed, Sep 12, 2018 at 2:10 PM robert engels <mailto:reng...@ix.netcom.c

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

> On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote: > >> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > <>googlegroups.com <http://googlegroups.com/>> wrote: >> >> [golang-nuts to CC, golang-dev to BCC] >> &g

Re: [go-nuts] Golang equivalent of Python's context manager

Yes, you are correct. My bad :) > On Sep 12, 2018, at 7:34 AM, Sebastien Binet wrote: > > > > On Wed, Sep 12, 2018 at 2:23 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > I am pretty sure that is not correct, I am referring to: > >> func WithCon

Re: [go-nuts] Golang equivalent of Python's context manager

Too early, and the coffee had not kicked in... > On Sep 12, 2018, at 7:49 AM, robert engels wrote: > > Yes, you are correct. My bad :) > >> On Sep 12, 2018, at 7:34 AM, Sebastien Binet > <mailto:bi...@cern.ch>> wrote: >> >> >> >> On Wed

Re: [go-nuts] Golang equivalent of Python's context manager

(and probably error prone) to use IMO, especially with Go’s multiple return values. > On Sep 12, 2018, at 7:50 AM, robert engels wrote: > > Too early, and the coffee had not kicked in... > >> On Sep 12, 2018, at 7:49 AM, robert engels > <mailto:reng...@ix.netcom.com&

[go-nuts] golang gRPC question

Hi, I am adding a remote component to my github.com/robaho/keydb project and decided to use gRPC. I’ve reviewed the docs, and it appears to want to be stateless - which given the nature of Google makes sense. But for something like a database connection, where t

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

as well as Java memory, or native memory. Go doesn’t need this, since the byte[] in Go is already a native pointer. > On Sep 12, 2018, at 8:15 AM, Egon wrote: > > On Wednesday, 12 September 2018 15:47:14 UTC+3, Robert Engels wrote: > I am well aware of mechanical sympathy and th

Re: [go-nuts] Golang equivalent of Python's context manager

ien Binet wrote: > > > > On Wed, Sep 12, 2018 at 2:55 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > Ok, now the coffee has kicked in, and it still has problems, because you > cannot call a method and use a return value other than error without multiple

Re: [go-nuts] [golang-dev] go doesn't need generics, but if they do...

it needs to match the platform. You can trust the JIT to perform better code optimization than most developers... > On Sep 12, 2018, at 8:34 AM, robert engels wrote: > > While I always appreciate a good presentation, a little color might be in > order to get me to watch a 1.5 hr

Re: [go-nuts] Go memory usage inside containers

With the Azul VM (and I believe the G1 collector in Java), the VM is definitely aware of memory pressure as it approaches the maximum limit - then it will increase the concurrent GC activity trying to avoid a potential huge pause if the limit was reached - so throughput is lowered. I would thin

Re: [go-nuts] Go memory usage inside containers

You would need to refer me to those articles. We used Java in containers all of the time. You need to set a proper -Xmx though. > On Sep 12, 2018, at 9:07 AM, robert engels wrote: > > With the Azul VM (and I believe the G1 collector in Java), the VM is > definitely aware of memory

Re: [go-nuts] golang gRPC question

The streaming mechanism seems to be the solution. Appears to be how cockroachdb does it. Sent from my iPhone > On Sep 12, 2018, at 2:47 PM, Josh Humphries wrote: > > >> On Wed, Sep 12, 2018 at 9:05 AM robert engels wrote: >> Hi, I am adding a remote component to my gi

Re: [go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

I think the idea of ‘field accessors’ is kind of scary. It is used all of the time in Java, but it happens there because Java has classes , so the generic can use a base class as a type - although most people do not do this for obvious reasons. Go interfaces only have methods. If generics are b

Re: [go-nuts] Go memory usage inside containers

This may be of interest. https://lists.linuxfoundation.org/pipermail/containers/2012-May/029798.html https://www.spinics.net/lists/cgroups/msg16842.html https://gi

Re: [go-nuts] Go memory usage inside containers

rote: > > On Wed, Sep 12, 2018 at 7:07 AM, robert engels wrote: >> With the Azul VM (and I believe the G1 collector in Java), the VM is >> definitely aware of memory pressure as it approaches the maximum limit - >> then it will increase the concurrent GC activity trying t

Re: [go-nuts] Go 2 error-handling: choose requirements!

Until Go has typed errors and a throws clause (I.e exceptions) it’s pointless. You need to be able to be certain errors are handled or passed up at compile time. The throws clause facilitates this. It allows refactoring without breakage. Until then just live with the boilerplate and keep your

Re: [go-nuts] A simplified generics constraint system.

> On Sep 14, 2018, at 12:16 PM, Ian Lance Taylor wrote: > > On Fri, Sep 14, 2018 at 3:32 AM, alanfo wrote: >> >> I was then brought back to reality by this post by Robert Engels in the >> 'Generics - Why contracts?' thread: >> >> "As I’ve s

Re: [go-nuts] [ANN] goey - Declarative, cross-platform GUIs

ut more work. > > - Robert > > > On Monday, 10 September 2018 14:25:05 UTC-4, Robert Engels wrote: > I wonder about the design, and how it will work. Since it uses the native > components behind the scene, you will get great fidelity but the layout can > be very difficu

Re: [go-nuts] Contracts and fused multiply add

Why do you need the for... Keywords with dual meaning is never a good idea. Sent from my iPhone > On Sep 15, 2018, at 4:53 AM, Wojciech S. Czarnecki wrote: > > On Wed, 12 Sep 2018 10:54:15 -0700 > jimmy frasche wrote: > >> because that misses cases like >> type Float float64 > > I am work

Re: [go-nuts] Contracts and fused multiply add

> On Sep 15, 2018, at 7:31 AM, Wojciech S. Czarnecki wrote: > > On Sat, 15 Sep 2018 06:36:35 -0500 > Robert Engels wrote: > >> Why do you need the for... > > Because 'for type' means 'contract' > Because CGG contracts are for each typeh

Re: [go-nuts] Why is go starting multiple child process?

It appears (on OSX at least) the minimum number of threads a Go process will be 5. You need to understand that there are multiple threads for usually the following reasons: signal handling, GC collection, monitoring, OS events, timers, and others. The number of threads is going to vary based on

Re: [go-nuts] Periodic task when time.Ticker and time.Sleep are pretty expensive

For reference, similar code under Java consumes 2.5 % CPU. I tested the Go code under OSX, and it is roughly 10%, which seems to be very high. Might be because the “context switching” is performed/attributed to the process (since it is internal), where for other systems it is the system call on

Re: [go-nuts] Why is go starting multiple child process?

You can use ‘top’ and use H to show threads. > On Sep 16, 2018, at 11:27 PM, the.warl0ck.1...@gmail.com wrote: > > There's no -T in Ubuntu 16.04, am I wrong? > > On Monday, September 17, 2018 at 11:54:05 AM UTC+8, Patrick Smith wrote: > Probably those are threads, not processes. Try 'pstree -T'.

Re: [go-nuts] Long time blocking CGO call affect and CGO/Go.syscall/Go.net/C IO performance

You can run my tests at github.com/robaho/go-network-test You will see that both Java and Go are 10% slower than pure C. In Java’s case it is mostly due to the ‘security checks’ that are run. In Go’s case I believe it is just the barrier from Go to C overhead as there are many more function call

Re: [go-nuts] Runtime threads/OS thread scheduling

Then it should be fairly trivial to call cgo to raise the priority of the ‘audio thread/routine after call runtime,LockOSthread() - nice ! > On Sep 17, 2018, at 1:36 PM, Ian Lance Taylor wrote: > > On Mon, Sep 17, 2018 at 10:39 AM, Scott Cotton wrote: >> >> Wanted to ask about the Go runtime

Re: [go-nuts] Re: I am not in favor of generics.

Here is a very common problem with generics... Everyone understands the concept of a tuple/pair. Pretty easy, you have getElement0 and getElement1 methods. Now a piece of code needs a KeyValue pair used in a map. So, with generics someone says, oh, I already have this pair class, I’ll just use

Re: [go-nuts] Re: I am not in favor of generics.

I am going to refer everyone involved in this discussion on generics to this once again. I know it is long, read the summary... but it’s important: https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics > On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki wrote: >

Re: [go-nuts] Re: I am not in favor of generics.

> On Sep 18, 2018, at 9:51 AM, Wojciech S. Czarnecki wrote: > > On Tue, 18 Sep 2018 08:19:13 -0500 > Robert Engels wrote: > >> So even when using generics you still need to be able to write >> understandable code. > > **need to be able to write understand

Re: [go-nuts] Re: I am not in favor of generics.

I’ve said many time, the CGG example you cite here is not generic code. If I want to pass a different user type and use that method I can’t, I need to change the source of Sum(). That is not generic programming... > On Sep 18, 2018, at 10:58 AM, Wojciech S. Czarnecki wrote: > > On Tue, 18 Sep

Re: [go-nuts] Re: I am not in favor of generics.

If you have type checking / casting / type select, whatever you want to call it in the “generic code”, it is not generic, and not re-usable. You can’t possibly know all the possible types, there may even be more additional primitive types, so the code is not resilient - Go 2.1 and all of your l

Re: [go-nuts] Re: I am not in favor of generics.

Go not having implements is a big problem when refactoring large Go systems especially because it doesn’t have generics - all type safety is gone and you fly by the seat of your pants. On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki wrote: >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc..

Re: [go-nuts] Re: I am not in favor of generics.

Also, I did read what you wrote. I questioned “what happens when you have N different generic types in the call signature. The select type statement has N*N cases. “. You did not respond. On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki wrote: >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhh

Re: [go-nuts] Re: I am not in favor of generics.

wrote: > > Huh? Type safety is still checked by the compiler. Implements does nothing > except put a road-block in the way and prohibit you from making an interface > that some other package happens to implement. > > On Wed, Sep 19, 2018 at 1:40 PM Robert Engels <mailto:re

Re: [go-nuts] Re: I am not in favor of generics.

This is not what I am referring to. I am stating that with N generics types in a method the developer needs to write NxN case methods. Not feasible. Sent from my iPhone > On Sep 19, 2018, at 9:25 AM, Wojciech S. Czarnecki wrote: > > On Wed, 19 Sep 2018 06:52:09 -0500 > Robert E

Re: [go-nuts] Re: I am not in favor of generics.

9, 2018 at 4:04 PM robert engels wrote: >> >> The opinion that well, since there is no implements I can define my own >> interface, and pass some stdlib struct that I can’t control as an >> “implementor” is hogwash. Because you also don’t control this code, the API &g

Re: [go-nuts] Re: Generic alternatives: new basic types?

Issues like these highlight the deficiencies of Go compared to Java. The Java designers understood languages far better, and from the start realized that identity and reference equality were different concepts. Everyone in Go land are debating these solved issues. Pick and chose what you want to

Re: [go-nuts] Re: Generic alternatives: new basic types?

st irritating and pervasive features of C type languages. I always > have to double and triple check. Even between some version changes C++ has > substantially disrupted the rules about it and I just don't think that > implicit casting is a good construct in a language. Implicit t

Re: [go-nuts] Re: Generic alternatives: new basic types?

you respect so much. > > That's either hypocritical or merely absurd in addition to the rather > inappropriate, unjustified and offensive ad hominem that accompanies > it. > > Lucio. > >> On 9/23/18, Robert Engels wrote: >> Issues like these highlight th

Re: [go-nuts] Re: Generic alternatives: new basic types?

short sighted IMO. > On Sep 23, 2018, at 12:13 PM, Lucio De Re wrote: > >> On 9/23/18, Robert Engels wrote: >> I take offense to that. I apologized for my statement that was worded more >> harshly than intended. But if you think that Go is beyond criticism just >> be

Re: [go-nuts] Generic alternatives: new basic types?

an instance of that type. In Go this happens with magic > compiler generics (len(x), cap(x), ...) that take any and all types and do > the right thing. I'm more a fan of no magic and a simple universal notion > that applies to every type, built-in or custom. > > In this sense,

Re: [go-nuts] Generic alternatives: new basic types?

documenting. I think type inference is lazy. Puts the burden on the maintainer forever when it would of been a small effort up front. For things like lambdas it makes a bit more sense but barely. Sent from my iPhone > On Sep 23, 2018, at 11:43 PM, Ian Denhardt wrote: > > Quoti

Re: [go-nuts] The If Statement: Switches are better except for a single condition (change my mind)

You should always return from the place of return, or goto return_label, when a result/error needs to be formatted. See the Knuth paper I posted a while ago on using goto... > On Sep 24, 2018, at 7:22 PM, Louki Sumirniy > wrote: > > Using named return values and this construction you can drop

Re: [go-nuts] The If Statement: Switches are better except for a single condition (change my mind)

tion. > >> On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: >> You should always return from the place of return, or goto >> return_label, when a result/error needs to be formatted. >> >> See the Knuth paper I posted a while ago on using goto... > &

Re: [go-nuts] run cmd and capture output on remote machine

You can do this via ssh. > On Sep 25, 2018, at 7:01 PM, Hemant Singh wrote: > > I have been able to run a command on a remote machine using Go. Is there a > working example that shows how to capture the output of the command back to > the client machine? Maybe an interactive shell... > >

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Based on my experience and I believe many others, I would caution against the use of pools. Although it can be useful for objects that are very expensive to create/initialize using it in a more general case just to improve GC can be fraught with issues in a highly concurrent and/or complex syste

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

developers “go” down the same path... > On Sep 27, 2018, at 8:29 AM, Peter Mogensen wrote: > > > >> On 09/27/2018 03:25 PM, Robert Engels wrote: >> Based on my experience and I believe many others, I would caution against >> the use of pools. Although it can be us

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

is added, it can become increasing difficult to perform manual reference counting - which is what you are doing... > On Sep 27, 2018, at 9:06 AM, Peter Mogensen wrote: > > > >> On 09/27/2018 03:58 PM, Robert Engels wrote: >> It wasn’t necessarily a warning to you :)

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

No offense, sorry for high jacking, I was trying to counter point their usefulness, as a way to limit additional resources being spent to improve GC when using them, since I think their application is error prone in many most? cases. > On Sep 27, 2018, at 9:30 AM, Peter Mogensen wrote: > >

[go-nuts] announce: LRMP - light weight reliable multicast protocol

I have ported LRMP (light weight reliable multicast protocol) to Go. It is available at lrmp There is also a Java implementation there, so it makes an ideal setup for local/wan notifications between processes/servers without a broker. The Java implementation was

Re: [go-nuts] Canonical module arrangement in a multi-language project.

The only thing I’ve found that works is the latter… and then I go yelled at that I wasn’t using proper structure… The only other choice is a different repo for the go code, and another repo for everything else. It doesn’t seem workable to me for large multi-language projects… but no one seems

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

Your description makes no sense. Why are you creating another C thread, you should just lock the OS thread the Go routine is on. Otherwise if you create another C thread, in the cgo call you need to block that thread or somehow communicate back into Go some other way - otherwise what is the poin

Re: [go-nuts] Constraints for generics

The static switch is a big problem. For any complex method you are going to completely duplicate all of the code. Not good. Far better to map operators to interfaces then you only need a single method implementation. > On Sep 30, 2018, at 5:33 AM, Christian Surlykke wrote: > > Hi > > I ma

Re: [go-nuts] Constraints for generics

ze++; modCount++; return null; } > On Sep 30, 2018, at 9:27 AM, Wojciech S. Czarnecki wrote: > >> Robert Engels wrote about what >>> Christian Surlykke wrote: > >> The static switch is a big problem. For any complex method you are going to >> completely d

Re: [go-nuts] Constraints for generics

, probably more so for the math operations. > On Sep 30, 2018, at 10:18 AM, robert engels wrote: > > Yes, it is a very similar if not the same issue, since the type switch must > be at the TOP LEVEL, you guarantee the entire method will be duplicated > multiple times. How you con

Re: [go-nuts] Constraints for generics

The non-collection cases can readily be solved with interfaces in most cases. > On Sep 30, 2018, at 10:32 AM, Scott Cotton wrote: > > > > On Sunday, 30 September 2018 13:04:55 UTC+2, Robert Engels wrote: > The static switch is a big problem. For any complex method you are

Re: [go-nuts] Constraints for generics

your, or proposals like it, will never be accepted. There’s just not enough added value for the primary use cases. > On Sep 30, 2018, at 1:09 PM, Wojciech S. Czarnecki wrote: > > On Sun, 30 Sep 2018 10:18:25 -0500 > robert engels wrote: > >> Yes, it is a very similar

Re: [go-nuts] net.TCPConn equivalent for setsockopt

use conn SetReadDeadline() > On Sep 30, 2018, at 8:41 PM, Dan Kortschak > wrote: > > I have been translating some C socket networking code (not my main area > of expertise) and there is something that I don't see a way to do with > net.TCPConn. > > The original code sets a revc timeout using >

Re: [go-nuts] net.TCPConn equivalent for setsockopt

But you need to set it on every call because it is an absolute time. > On Sep 30, 2018, at 9:03 PM, robert engels wrote: > > use conn SetReadDeadline() > >> On Sep 30, 2018, at 8:41 PM, Dan Kortschak >> wrote: >> >> I have been translating some C sock

Re: [go-nuts] net.TCPConn equivalent for setsockopt

This may help https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/ > On Sep 30, 2018, at 9:04 PM, robert engels wrote: > > But you need to set it on every call because it is an absolute time. > >> On Sep 30, 2018, at 9:03 PM, robert engels wrot

Re: [go-nuts] net.TCPConn equivalent for setsockopt

That brings up a problem I have with the way godoc is generated/provided. If you go to the TCPConn SetReadDeadline function, it states “implements the Conn SetReadDeadline method”, with no way of referencing the documentation for Conn.SetReadDeadline, in fact, no way of even getting to the Conn

Re: [go-nuts] net.TCPConn equivalent for setsockopt

> On Oct 1, 2018, at 4:59 PM, Ian Lance Taylor wrote: > > On Mon, Oct 1, 2018 at 1:53 PM, robert engels wrote: >> >> If you go to the TCPConn SetReadDeadline function, it states “implements the >> Conn SetReadDeadline method”, with no way of referencin

Re: [go-nuts] net.TCPConn equivalent for setsockopt

t 1, 2018, at 6:00 PM, robert engels wrote: > > >> On Oct 1, 2018, at 4:59 PM, Ian Lance Taylor > <mailto:i...@golang.org>> wrote: >> >> On Mon, Oct 1, 2018 at 1:53 PM, robert engels > <mailto:reng...@ix.netcom.com>> wrote: >>> >

Re: [go-nuts] net.TCPConn equivalent for setsockopt

Great, maybe I can find some time and contribute back… I think it would go a long way towards working with complex hierarchy systems easier. > On Oct 1, 2018, at 11:36 PM, Agniva De Sarker > wrote: > > > > On Tuesday, 2 October 2018 04:30:54 UTC+5:30, Robert Engels wro

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Yes, lobby to have Go2 include exceptions and then you don’t need to worry about any of this... :) > On Oct 8, 2018, at 5:38 AM, Chris Hopkins wrote: > > Hi, > Could I please check what current error handling best practice is? > I've gotten quite smitten with github.com/pkg/errors. I really lik

Re: [go-nuts] Error Handling Best Practice (error wrapping)

I read the proposal and the only knock against including a stack trace by default is one google problem cited that was clearly bad error handling to begin with. Why is there always some need to reinvent the wheel. Leave Go error handling as in and add a throws and catch that new code can use,

Re: [go-nuts] Error Handling Best Practice (error wrapping)

every one of those > places to use different errors, but I would hope most people would say that > that behaviour was bad practice, to be fixed. I believe exceptions would > encourage, not discourage that behaviour. > > Sorry, my short post ended up quite long too! > &

Re: [go-nuts] Error Handling Best Practice (error wrapping)

er ziz fifz yer, ve vil hav a reil sensi bl >> riten styl. >> >> Zer vil be no mor trubl or difikultis and evrivun vil find it ezi TU >> understand ech oza. Ze drem of a united urop vil finali kum tru. >> >> Und efter ze fifz yer, ve vil al be speking German l

Re: [go-nuts] Error Handling Best Practice (error wrapping)

t 8:23 PM, Dan Kortschak > wrote: > > That is uncalled for. > > Dan > >> On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote: >> I don’t think denigrating the most obvious advancement in computer >> software in the last 20 years helps move things forward.

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Java has already solved suggests to me on balance that I haven't. > If I have, I apologise. > > I have nothing further to add to this thread. > > Dan > >> On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote: >> I was only speaking for James Gosling. Engineer

Re: [go-nuts] Error Handling Best Practice (error wrapping)

instead just use the tool you’ve backed you’re bound to fail. Sent from my iPhone > On Oct 8, 2018, at 11:10 PM, Robert Engels wrote: > > I’m sorry you feel that way. None of my comments on Go were intended to be > abrasive, they were intended to be matter of fact. > > You ar

[go-nuts] async IO

It was my understanding that all IO in Go was async, and that behind the scenes when you made a network read, it enqueued the fd, descheduled the Go routine, and performed a select/poll on some other thread, then based on the select, it would rescheduled the proper Go routine to perform the rea

Re: [go-nuts] async IO

ote: > > On Wed, Oct 10, 2018 at 9:35 AM, robert engels wrote: >> >> It was my understanding that all IO in Go was async, and that behind the >> scenes when you made a network read, it enqueued the fd, descheduled the Go >> routine, and performed a select/poll on

Re: [go-nuts] Using a defer func() closure to call c.free

Are you sure the document is not doing the free of the file and the opt when it is destroyed? It might need those references beyond the function scope. > On Oct 11, 2018, at 3:52 AM, ndav...@turnitin.com wrote: > > > package main > > /* > #cgo CFLAGS: -g -Wall -I/usr/local/include > #cgo LDFL

Re: [go-nuts] Using a defer func() closure to call c.free

It is not necessarily the open doc that is freeing the memory, could be the close doc as well - meaning it needs the file and opt reference while it is open. Probably not file, but possible opt. The other thing are you sure that the opt doesn’t contain a reference that is freed to early... > On

Re: [go-nuts] Temporary files in go

I think a more “standard” and certainly portable way to do this is with a tmp file, and a rename/move at the end - along with a clean-up of tmp at application start (if worried about crashes). Using the proper file and process permissions on the tmp file - since you need these to protect the fi

Re: [go-nuts] Temporary files in go

Which is not Windows, which is giving up a lot of options, and is important to some people, where as just using tmp files is ok. I am not even sure if windows supports deleting an open file yet. > On Oct 12, 2018, at 3:09 AM, Beoran wrote: > > linkat() and openat() are posix 2008 standard func

Re: [go-nuts] Go language should become an ANSI and ISO standard.

This may be of interest https://www.computer.org/csdl/proceedings/hicss/2001/0981/05/09815015.pdf > On Oct 13, 2018, at 12:18 PM, alanfo wrote: > > May I remind those who are in favor of Go standardization that Java and > Python have never been standardized by ISO/ANSI/ECMA but that hasn't >

  1   2   3   4   5   6   7   8   9   10   >