Re: [go-nuts] Is this implementation of weak pointers safe?

On Sunday, September 30, 2018 at 6:53:47 PM UTC-5, Dave Cheney wrote: > > Please don’t take os.File as justification, it’s one of the few uses of a > finaliser in the std lib. If it were being written today I would argue that > instead of silently closing the file, it should panic if the resource

[go-nuts] 2018/09/29 23:50:19 go-app-builder: Failed parsing input: parser: bad import "syscall" in main.go

Maybe syscall in banned in appengine? -- 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://gr

Re: [go-nuts] cgo use question

You could export the C function in a Go wrapper in package A, and use that. Maybe another exported Go wrapper is needed in package B, I don't know. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

[go-nuts] Re: Announcing pytogo. a crude but surprisingly effective Python to Go translator

Thanks, I'll fix the bug and add that to my test loads. > > I discovered earlier today that an incautious rule steps on lambda expressions and some kinds of slice indexing. The risks of not using a parser... Until I ship 1.1 (shortly, probably tomiorrow), I recommend filtering your file in sma

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

Yeah, I looked at that. It doesn't look like a good solution. On Sun, 2018-09-30 at 21:03 -0500, robert engels wrote: > use conn SetReadDeadline() > > > > > On Sep 30, 2018, at 8:41 PM, Dan Kortschak > edu.au> wrote: > > > > I have been translating some C socket networking code (not my main >

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 wrote: >> >> use conn SetRead

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 socket networking code (not my main area >> o

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 >

[go-nuts] net.TCPConn equivalent for setsockopt

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 ``` setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout)); ``` Short of messing aro

Re: [go-nuts] Is this implementation of weak pointers safe?

Please don’t take os.File as justification, it’s one of the few uses of a finaliser in the std lib. If it were being written today I would argue that instead of silently closing the file, it should panic if the resource falls out of scope unclosed. As always, remember that finalisers are not g

Re: [go-nuts] Is this implementation of weak pointers safe?

On Sunday, September 30, 2018 at 4:56:20 PM UTC-5, Kane York wrote: > > In Go, it's usually better to use source code analysis to look for > forgotten Close calls, like the existing tooling for os.File (which does > have a finalizer, but doesn't need to). *os.File has a finalizer for the same r

[go-nuts] Re: Announcing pytogo. a crude but surprisingly effective Python to Go translator

Thanks for sharing this (and I'm honored to make your virtual acquaintance, Eric). I'd love to make use of pytogo my own project. I've got a little over 20K lines that still need translation. So I cloned it and gave it a quick try. It seems to be choking on doc strings of the form. """ Som

[go-nuts] 2018/09/29 23:50:19 go-app-builder: Failed parsing input: parser: bad import "syscall" in main.go

Hi, Anyone has encountered this error before when trying to run your app in app engine console: dev_appserver.py app.yaml 2018/09/29 23:50:19 go-app-builder: Failed parsing input: parser: bad import "syscall" in main.goWARNING 2018-09-29 23:50:19,127 instance.py:297] Could not get PID of ins

Re: [go-nuts] Is this implementation of weak pointers safe?

In Go, it's usually better to use source code analysis to look for forgotten Close calls, like the existing tooling for os.File (which does have a finalizer, but doesn't need to). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe f

Re: [go-nuts] Constraints for generics

Using a subset of types makes it unusable for generic collections. You don’t want to write multiple tree maps. That is what Go has today and what generics is primarily attempting to fix, so at the end of the day if I can’t write a completely generic collection class I will bet the farm that your

Re: [go-nuts] Constraints for generics

On Sun, 30 Sep 2018 10:18:25 -0500 robert engels wrote: > Yes, it is a very similar if not the same issue, > since the type switch must be at the TOP LEVEL No, in my CGG `for type switch` contract does not need to be at top level. It is proposed in Chris' but still yours: > you guarantee the e

Re: [go-nuts] Constraints for generics

On Sun, 30 Sep 2018 at 17:56, robert engels wrote: > > I think you address the first, with a “toUnsigned” method, but I am not sure > that semantically makes sense for a lot of types except numerics, but > “shifting” is only supported on numeric types anyway. > > I have always thought that not h

Re: [go-nuts] cgo use question

On Sun, 30 Sep 2018 at 17:55, Simon Ritchie wrote: > > Aagh! I misunderstood the question. Apologies for that. > I could have phrased the question more clearly also, sorry. > There may still be a grain of usefulness in my answer. There are limits to > the complexity of the C code that you c

Re: [go-nuts] Constraints for generics

I think you address the first, with a “toUnsigned” method, but I am not sure that semantically makes sense for a lot of types except numerics, but “shifting” is only supported on numeric types anyway. I have always thought that not having automatic conversions for numerics in Go is a bit strang

[go-nuts] cgo use question

Aagh! I misunderstood the question. Apologies for that. There may still be a grain of usefulness in my answer. There are limits to the complexity of the C code that you can call with cgo. (It’s even worse if you are calling C++, as I was.) You can magic away a lot of those problems by writ

Re: [go-nuts] Constraints for generics

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 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.

Re: [go-nuts] Is this implementation of weak pointers safe?

On Sunday, September 30, 2018 at 4:00:32 AM UTC-5, Tamás Gulácsi wrote: > > 2018. szeptember 30., vasárnap 6:20:37 UTC+2 időpontban Ben Lubar a > következőt írta: >> >> On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote: >>> >>> Quoting Ben Lubar (2018-09-29 14:40:28) >>> >

Re: [go-nuts] Constraints for generics

Btw, I realize that in this particular case, you would probably write a “compareKeys” method to perform the key comparison, and that would have the type switch, but I was trying to show that in general a method that uses a lot of math and or comparison operations will need to be duplicated, prob

Re: [go-nuts] Constraints for generics

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 continually do not see the problem with this I am not sure, but I think it is because you are using trivial methods to “test

Re: [go-nuts] cgo use question

Hi again, As a followup, it seems the same or similar problems occur with assigning function pointers across Go packages via cgo. When trying to assign a C function "fC" defined via cgo in package A to a C function pointer "fCPtr" in package B, even at runtime via Go, I get: Undefined symbols

Re: [go-nuts] Constraints for generics

> Robert Engels wrote about what >> Christian Surlykke wrote: > The static switch is a big problem. For any complex method you are going to > completely duplicate all of the code. Not good. Now the same straw man argument I read in "critique" about my [1] solution is raised against other per

[go-nuts] Re: Constraints for generics

Hi, Just a couple of friendly notes / impressions: I couldn't help but notice how many new gramars, or additions would need to be added to the language in order to support a feature aiming to be simple, in a language where one of the top driving goals it to be as simple as possible. Also no bui

Re: [go-nuts] cgo use question

Hi all, For info, short of a solution for linking cgo specific C functions cross package, I think one can do this with C function pointers, which at least is a close approximation of directly calls. Best, Scott On Sunday, 30 September 2018 14:08:28 UTC+2, Scott Cotton wrote: > > Thanks > > In

Re: [go-nuts] using 'go function_call()' inside Go program

Hi Justin, Got it - thanks much! Hemant On Saturday, September 29, 2018 at 11:58:30 PM UTC-4, Justin Israel wrote: > > > > On Sun, Sep 30, 2018 at 3:47 PM Hemant Singh > wrote: > >> I have a question. I have changed the open goping.go code to return >> error from functions. >> >> The follow

Re: [go-nuts] cgo use question

Thanks In my case, believe it or not -- and for a very particular use case, I cannot call the shared C functionality from Go, it must be called from C. And I want to avoid telling consumers to use make to create a C library, so that go get and modules will work. It looks to me like your solution,

[go-nuts] cgo use question

Write a separate package to handle the C stuff and call it from the other two. I built a wrapper for a c++ library: https://github.com/goblimey/rplidar_sdk_go. The c++ code used various features that defeated cgo, so I ended up with a multi-layered solution. One thing I discovered is that cg

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

[go-nuts] Announcing pytogo. a crude but surprisingly effective Python to Go translator

I have mentioned before on this list that I am engaged in source translation of a largeish Python prgram - 14KLOC - to Go. I found the automated AST-based translation tools already available unsatisfactory; they don't produce a quality of Go code I would consider maintainable. So I wrote my o

[go-nuts] Constraints for generics

Hi I made a proposal for generics with constraints about ½ a year ago, which I posted to the (very long) thread on issue 15292. I've now made a version 2 , in case anybody would like to read it. This version adapts to the ge

Re: [go-nuts] Is this implementation of weak pointers safe?

2018. szeptember 30., vasárnap 6:20:37 UTC+2 időpontban Ben Lubar a következőt írta: > > On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote: >> >> Quoting Ben Lubar (2018-09-29 14:40:28) >> >[1]https://play.golang.org/p/iBAii-f84Sq >> >vet is complaining because the