[go-nuts] Re: non-standard json

2018-11-03 Thread Amnon Baron Cohen
Try something like https://play.golang.org/p/eHEjKINz9aW func extract(r io.Reader) { dec := json.NewDecoder(r) for { var el s err := dec.Decode(&el) if err == io.EOF { break } log.Println(el) } } On Thursday, 1 November 2018 16:14:17 UTC, Alex Dvo

[go-nuts] Re: discuss database/sql feature request: add ability to retrieve driver.Driver by registered driver name.

2018-11-03 Thread Bas Van Beek
Let's make that happen. I agree the better long term solution would be hooks in the same vain of http's net/http/httptrace. Wrapping drivers and keeping them in sync with each new Go release is quite tedious with enhancement interfaces, updated API's and such. Having a hooks solution would be d

Re: [go-nuts] Code generated by generics draft

2018-11-03 Thread roger peppe
In case it's of interest, I've been playing around with an experiment about how Go generic code might be generated. In particular I wanted to see how it looked when code was shared between generic instances with types that share the same memory layout (with respect to internal pointers and alignmen

Re: [go-nuts] Code generated by generics draft

2018-11-03 Thread roger peppe
Ah, I should mention it relies on a slightly modified version of the compiler that allow conversion of function values to and from unsafe.Pointer. It can be done without that, but not without extra heap allocations AFAIK, and part of the point of this exercise was to measure runtime overheads. On

Re: [go-nuts] Code generated by generics draft

2018-11-03 Thread Mandolyte
Sorry for the ambiguity. As I understand it, the "fo" compiler simply rewrites the generic function/method using the supplied type parameters and then tries to compile it. It would be an interesting exercise to try the Graph example, but as it is, I'm not certain how it would handle it, or if i

Re: [go-nuts] Code generated by generics draft

2018-11-03 Thread Ian Denhardt
>Ah, I see. the albrow/fo package is the equivalent of just pasting the >entire function into the contract. It's not actually -- the rules seem to be those of the draft design, with the contracts mechanism simply omitted. So e.g. there's no way to write a max function; see: https://

[go-nuts] Re: Announcing: Skylark in Go

2018-11-03 Thread adonovan via golang-nuts
Starlark is the new name for the Skylark configuration language. (The old name was the code name for a subproject of Bazel and was not suitable for a project in its own right.) The Starlark in Go implementation has moved. The code is now hosted at https://github.com/google/starlark-go but

[go-nuts] Re: non-standard json

2018-11-03 Thread Manlio Perillo
On Thursday, November 1, 2018 at 5:14:17 PM UTC+1, Alex Dvoretskiy wrote: > > Is there is a way to read a file line by line and extract JSON data from > it? > > > Example: > > file: > ` > value1: {"field1": "123, "field2": "123"} > value2: {"field1": "456", "field2": "879"} > > ` > > Of cour

Re: [go-nuts] Code generated by generics draft

2018-11-03 Thread roger peppe
Here's a version that runs in the playground. https://play.golang.org/p/DciTAl8dAxO On Sat, 3 Nov 2018 at 11:45, roger peppe wrote: > Ah, I should mention it relies on a slightly modified version of the > compiler that allow conversion of function values to and from > unsafe.Pointer. It can be d

Re: [go-nuts] Code generated by generics draft

2018-11-03 Thread Wojciech S. Czarnecki
On Sat, 3 Nov 2018 11:21:30 + roger peppe wrote: > In case it's of interest, I've been playing around with an experiment about > how Go generic code might be generated. I've been playing around in the CGG proposal context, too. Unfortunately my spare time shrunk recently. You did more so I j

Re: [go-nuts] Code generated by generics draft

2018-11-03 Thread Burak Serdar
On Sat, Nov 3, 2018 at 2:12 PM Wojciech S. Czarnecki wrote: > > > Future: I'll consider Burak Sedar's **like Type** within CGG contract. fyi: I got some useful feedback on this, especially from Scott Cotton, and I am working on some sort of formal framework (using go 1) where I can test if this i

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

2018-11-03 Thread Andy Balholm
I thought of a way to do something similar to the “implements” proposal without introducing operator overloading: turn it around. Instead of letting methods implement operators, we could let operators implement methods. type Lesser(type T) interface { Less(b T) bool for(<) } This interf

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

2018-11-03 Thread Ian Denhardt
Quoting Andy Balholm (2018-11-03 16:40:39) > But if a mis-matched type was passed to Less, it would need to panic. > So this option (using the Self type) would somewhat reduce > compile-time type safety. This is why I left `self` out of my own proposal; while I agree it would be more ergonomic, i

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

2018-11-03 Thread Lucio
On Saturday, 3 November 2018 22:41:08 UTC+2, Andy Balholm wrote: > > I thought of a way to do something similar to the “implements” proposal > without introducing operator overloading: turn it around. Instead of > letting methods implement operators, we could let operators implement > methods.

[go-nuts] googleable guru doc page?

2018-11-03 Thread 'Jeff Hodges' via golang-nuts
Hey, I just googled "guru golang" and "go guru" and wasn't able to find documentation on what guru can do or how it does it. Is there documentation for it that could be made search accessible somewhere? Or is guru deprecated and I hadn't heard? -- You received this message because you are subscr