[go-nuts] Re: slog formatter funcs? (e.g. slog.Infof)

[Jonathan Amsterdam]

I personally am a fan of formatted logs, but we didn't see a way to combine 
them with key-value pairs (you only get one variadic arg per function call).
It wouldn't be hard to write a layer that wraps a slog.Logger or 
slog.Handler with xxxf functions. That's what I recommend.
On Friday, December 15, 2023 at 2:19:22 AM UTC-5 Uli Kunitz wrote:

> The documentation of the package says this: "Package slog provides 
> structured logging, in which log records include a message, a severity 
> level, and various other attributes expressed as key-value pairs."
>
>
> If you are using string formatting you are not producing key-value pairs. 
> Following the structured logging philosophy your example should be 
> slog.Error("func returned error", "err", err). I would include a second 
> key-value pair "func", "" too. 
>
>
> Such key value pairs are much easier to filter by log management and 
> processing tools than formatted strings. It also helps to reduce the CPU 
> consumption of the logging function itself. The slog package provides the 
> LogAttrs function for that purpose.
> On Wednesday, December 13, 2023 at 3:30:53 AM UTC+1 Billy Lynch wrote:
>
>> Hi!
>>
>> I've been playing around with the new slog package, and I noticed that it 
>> was missing formatter funcs (Infof, Errorf, etc). I'm interested in adding 
>> these, but I wasn't sure if this was done intentionally since the godoc 
>> calls 
>> out this type of functionality in examples 
>> . 
>>
>> Helpers have been suggested as a workaround for this 
>> , but 
>> this is common enough behavior for me that I think it'd be very helpful to 
>> have upstream to make it easy to do things like: slog.Errorf("error calling 
>> func: %v", err)
>>
>> Rough idea would be do expose formatter functions in the Logger 
>> , with the tradeoff that you replace 
>> formatter args for Attr args:
>>
>> ```go
>> func (l *Logger) Errorf(format string, args ...any) {
>> l.log(context.Background(), LevelError, fmt.Sprintf(msg, args...))
>> }
>>
>> func (l *Logger) ErrorContextf(ctx context.Background(ctx 
>> context.Context, format string, args ...any) {
>> l.log(ctx, LevelError, fmt.Sprintf(msg, args...))
>> }
>> ```
>>
>> I wanted to check in before I opened an issue! 
>> Let me know if this makes sense, or if there's context I'm missing.
>>
>> Thanks!
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3660a04f-d4d6-4ed5-b364-c9c49efab060n%40googlegroups.com.

[go-nuts] Re: possible bug in slog.Value json marshaling

[Jonathan Amsterdam]

Hi Steve,
I'm not sure what the right answer is. Can you file this as a bug on 
go.dev/issues?

On Thursday, September 7, 2023 at 2:30:09 PM UTC-4 Steven Pelley wrote:

> Hi everyone,
>
> Possibly a bug or potential improvement in slog.
> This will sound excessively complicated, which I recognize and have 
> changed my approach.  Regardless, I see an opportunity to improve 
> surprising behavior.
> I'm looking for feedback on whether I missed something in the slog 
> documentation or if this is a valid bug or improvement, in which case I can 
> file it.
>
> slog.Value always json.marshals to an empty document, "{}", which to me 
> was surprising behavior when using JsonHandler.  If a slog.Value is 
> embedded in a logged non-slog.Value, for example a slice, it will 
> effectively omit data.  On the other hand any tree of Values and Attrs 
> passed directly to the log functions, without an intervening non-slog.Value 
> object, marshals and logs properly.  I expect a slice, or any other 
> non-slog.Value type, containing an slog.Value to marshal to json with the 
> slog.Value's represented value.
>
> Alternatively, the slog documentation (or specifically JsonHandler) could 
> state that no non-slog.Value object passed to a log method may contain an 
> slog.Value, and that LogValuers must maintain this invariant.
>
> go1.21.0 darwin/arm64
> demonstration 
>
> I discovered this when logging (using JsonHandler) an object containing a 
> list of objects whose logged data I wanted to redact/reduce.  I do this as 
> a LogValuer whose LogValue function constructs and returns a new 
> slog.GroupValue with a []slog.Value containing the redacted objects for 
> logging.  Each Value is created by in turn calling 
> Value.Resolve(Value.anyValue(...)) on the component items.  The resulting 
> log contains a list of empty documents.  I think this is a reasonable use 
> of LogValue, though I recognize that many people will suggest not logging 
> slices.
>
> Thanks,
> Steve
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/04a3cff1-557f-4642-a3f3-479266b7a6dbn%40googlegroups.com.

[go-nuts] [ANN] type-safe templates

[Jonathan Amsterdam]

The latest version of github.com/jba/templatecheck[0] supports templates
that cannot have type errors at execution time.

Once you've parsed your template `t` and all associated templates, call

   ct, err := templatecheck.NewChecked[MyData](t)

If err == nil, then ct is a CheckedTemplate[MyData]. Its Execute method
will only accept a MyData, and execution will not fail because your
template tried to access a field that didn't exist, or tried to range over
something that doesn't support range, or any other problem related to types.

To make this guarantee, the type checker enforces a stricter semantics than
the usual one for templates. For example, when you create a variable with a
value, like this:

{{$v := 1}}

then all assignments to that variable must use the same type. Assignments
that are normally valid, like

{{$v = ""}}

will fail this stricter check.

Also, since there is no way to declare the type of a template created with
{{define "T"}}, all calls to such templates must use the same type for dot.

If you can live with these restrictions, you might like using
CheckedTemplate[T] for the extra safety it provides.

I'd like feedback on how difficult the stricter semantics is to work with.
In particular, how painful is the restriction that all calls to associated
templates must have the same type?

I'd also consider proposing this for the standard library if a lot of
people like it.

[0] https://pkg.go.dev/github.com/jba/templatecheck

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEymQsSqVjw4KXVUvz2k6s9Hup4mgjUZ-DZWcn%3DH1FmbuJUXdg%40mail.gmail.com.

[go-nuts] Re: wtf

[Jonathan]

Defer evaluates the arguments to the deferred func at the point  of the 
defer statement.
On Saturday, August 26, 2023 at 10:58:06 AM UTC-4 Aln Kapa wrote:

> Hi All ! 
> Need some help, what am I doing wrong?
>
> https://go.dev/play/p/bBlA-i1CxNO
>
> // You can edit this code!
> // Click here and start typing.
> package main
>
> import (
> "errors"
> "fmt"
> )
>
> type process struct {
> }
>
> func (p *process) close(err error) {
> if err != nil {
> fmt.Println("error")
> } else {
> fmt.Println("no error")
> }
> }
> func Handle(b bool) {
> p := process{}
> var err error
> defer func() {
> p.close(err)
> }()
> if b {
> err = errors.New("err")
> }
> }
>
> func HandleWTF(b bool) {
> p := process{}
> var err error
> defer p.close(err)
> if b {
> err = errors.New("err")
> }
> }
>
> func main() {
> Handle(true)// error
> Handle(false)   // no error
> HandleWTF(true) // no error ?
> }
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b72045bb-8a6f-4835-8f1a-3241e9b1dbf9n%40googlegroups.com.

[go-nuts] Re: slog's use of runtime.Callers() with a skip

[Jonathan Amsterdam]

The Go runtime does the right thing.

On Friday, August 11, 2023 at 8:58:53 AM UTC-4 jake...@gmail.com wrote:

> As far as I can tell, skip works even in the face of inlined functions, at 
> least when used with runtime.CallersFrames(). It would be surprising  to me 
> if it did not. Do you have any evidence to the contrary?
>
> On Friday, August 4, 2023 at 9:51:34 AM UTC-4 sh...@tigera.io wrote:
>
>> I was looking at replacing logrus with the new slog library in our 
>> project.  I noticed that it uses runtime.Callers() with a fixed skip 
>>  
>> to collect the PC of the calling code, presumably to make it possible for 
>> the handler to emit line number and filename.
>>
>> Question is: is that sound in the face of inlining functions?  I think if 
>> the Info method gets inlined then the skip might be too large, for example.
>>
>> I remember having to change similar code in our project to use 
>> runtime.CallersFrames in order to deal with inlining. Quite possible 
>> there's a way to deal with an inlined PC that I wasn't aware of, but it 
>> seemed wrong to me.
>>
>> -Shaun
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2b25c687-1dd3-4c15-a0b8-cc13e3ca8e43n%40googlegroups.com.

Re: [go-nuts] What happened to sep in errorrs.join

['Jonathan Amsterdam' via golang-nuts]

I think you can do what you want with `HandlerOptions.ReplaceAttr`. It is 
given every attribute, even the message.
It can't change the group names, though, and those can have newlines.


On Tuesday, August 8, 2023 at 5:47:38 PM UTC-4 Ian Lance Taylor wrote:

> [ + jba ]
>
> On Tue, Aug 8, 2023 at 4:24 AM Joseph Lorenzini  wrote:
> >
> > Thanks that was very helpful. As for your point about slog, yes a custom 
> handler could but I am using the library json handler.
> >
> > I suppose the proper way to frame my problem is that I am using the slog 
> library handler and I do not want new lines in the message or keys.
> >
> > Would the go team would be open to providing knobs to control how the 
> handler does formatting? I assumed if I tried opening a proposal like that 
> I’d be told to write a custom handler. :)
> >
> > On Mon, Aug 7, 2023 at 3:56 PM Ian Lance Taylor  
> wrote:
> >>
> >> On Mon, Aug 7, 2023 at 4:32 AM jal...@gmail.com  
> wrote:
> >> >
> >> > In the errors.join proposal, the proposed api had the user specify 
> how they wanted the errors to be formatted together. But the actual 
> implementation omitted and only used new line.
> >> >
> >> > This is quite unfortunate if you are using slog and want to log that 
> error and very much need a log statement to not span multiple lines. It 
> also makes it much harder to read.
> >> >
> >> > Does anyone recall why sep was dropped?
> >>
> >> See the discussion at https://go.dev/issue/53435, especially
> >> https://github.com/golang/go/issues/53435#issuecomment-1190654775 and
> >> https://github.com/golang/go/issues/53435#issuecomment-1190845424.
> >>
> >> As far as the slog package it seems to me that a handler can enforce
> >> that individual messages are on a single line. There may be a better
> >> way to address that problem, but I don't think that errors.Join is the
> >> right place for a fix. Any random package can generate multiline
> >> error messages with errors.New("a\nb"), and I've seen plenty that do.
> >> So enforcing single-line messages on errors.Join won't fix the problem
> >> in general.
> >>
> >> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e9f2b5a1-d782-48a3-a073-00dc4087c0d9n%40googlegroups.com.

Re: [go-nuts] Re: Types like http.Request and slog.LogValuer

['Jonathan Amsterdam' via golang-nuts]

Another idea: write a handler that wraps whatever handler you usually use.
That handler looks through the Record for attr values of type
*http.Request, and replaces them with whatever formatting you want.
You might even be able to do that with a ReplaceAttr function with the
built-in handlers.

On Sat, Jul 29, 2023 at 10:23 AM Jens-Uwe Mager  wrote:

> There is a slight problem here that the requestWrapper would have to be
> implemented very deep through many layers of library. For example there
> might be a data structure passed down a chain of handlers with a custom
> argument structure, which contains a http.Request per some old design
> decisions. Switching to slog probably makes me revisit this design, as I
> cannot easily get the http.Request out of that structure easily. And this
> custom structure is logged all over the place.
>
> Oh well.
>
> On Saturday, July 29, 2023 at 12:18:53 PM UTC+2 Jonathan Amsterdam wrote:
>
>> I would write a type that wraps the request and implements LogValuer.
>> Then you would log the request as
>>
>>  logger.Debug("req", "r", requestWrapper{r})
>>
>> On Thursday, July 27, 2023 at 10:01:27 AM UTC-4 Jens-Uwe Mager wrote:
>>
>>> I am trying to convert some older code to slog and I am running into the
>>> issue that if some data structure contains http.Request I get the message:
>>>
>>> {"time":"2023-07-27T15:49:04.744214+02:00","level":"DEBUG","msg":"req","r":"!ERROR:json:
>>> unsupported type: func() (io.ReadCloser, error)"}
>>>
>>> So I believed it would be a good idea to add a LogValue() function to
>>> http.Request that used httputil.DumpRequest(), but that does not work as I
>>> cannot add methods from my code. Any good idea to approach that?
>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/PYIIhY6pNM4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a42d3bce-86d0-43dd-8895-4bd3a524cddfn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/a42d3bce-86d0-43dd-8895-4bd3a524cddfn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOqyxwLibjE7TCFy5kiGsgORYzb2O5-EptBOZ2chT6tuQEaeZg%40mail.gmail.com.

[go-nuts] Re: Using log/slog with log.Logger format?

['Jonathan Amsterdam' via golang-nuts]

We don't plan on exposing the commonLogger implementation, but you can 
write your own handler to get the exact format you want.

See github.com/jba/slog/handlers for some existing code.
See https://github.com/golang/example/tree/master/slog-handler-guide for a 
guide to writing a slog handler.

On Saturday, July 22, 2023 at 9:22:42 AM UTC-4 cpu...@gmail.com wrote:

> Seems it's not possible to create a logger using the log.Logger format in 
> a straight-forward way?
>
> On Thursday, July 20, 2023 at 3:48:49 PM UTC+2 cpu...@gmail.com wrote:
>
>> The log/slog logger uses the log.Logger format by default. Implementation 
>> is internal.
>>
>> In a gradual switch to slog I'd like to keep that format for time being 
>> but customize other handler options- hence need to create a new Logger. Is 
>> there a good way to do that without reimplementing the entire internal slog 
>> logic around commonHandler etc?
>>
>> Cheers,
>> Andreas
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/74cd209a-60f6-4be0-969c-b48d0d5b5251n%40googlegroups.com.

[go-nuts] Re: Types like http.Request and slog.LogValuer

['Jonathan Amsterdam' via golang-nuts]

I would write a type that wraps the request and implements LogValuer. Then 
you would log the request as

 logger.Debug("req", "r", requestWrapper{r})

On Thursday, July 27, 2023 at 10:01:27 AM UTC-4 Jens-Uwe Mager wrote:

> I am trying to convert some older code to slog and I am running into the 
> issue that if some data structure contains http.Request I get the message:
>
> {"time":"2023-07-27T15:49:04.744214+02:00","level":"DEBUG","msg":"req","r":"!ERROR:json:
>  
> unsupported type: func() (io.ReadCloser, error)"}
>
> So I believed it would be a good idea to add a LogValue() function to 
> http.Request that used httputil.DumpRequest(), but that does not work as I 
> cannot add methods from my code. Any good idea to approach that?
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/64cac638-52a5-43ea-a68b-73544bf3fad7n%40googlegroups.com.

[go-nuts] call for data on HTTP routing

['Jonathan Amsterdam' via golang-nuts]

At https://github.com/golang/go/discussions/60227, we're discussing 
enhancements to the standard library's http.ServeMux routing. Two issues 
have arisen that we could use your help on.

The first is easy to state: does fast routing matter? Are there Go web 
servers for which http.ServeMux is too slow, where it consumes a 
significant fraction of the serving latency? My position (which is also the 
null hypothesis) is that no, for the vast majority of applications routing 
time is noise. Some evidence for that: the gorilla/mux router  
(https://github.com/gorilla/mux) is about 60 times slower than the fastest 
routers, but as far as we can tell it's still widely used (despite being 
unmaintained for two years). Change my view! Do you have a production 
service for which you had to abandon http.ServeMux because it was too slow? 
Tell me about it. Specific routing schemes and benchmarks are a plus.

The second question is about a specific routing scheme, and here I have no 
preconceived notions. Here is the context: given two routing patterns that 
might otherwise conflict, we'd like to allow both by preferring one over 
the other, where this makes sense. Currently, we prefer a pattern that 
specifies a method over one that doesn't; and after that, we prefer a 
pattern with a more specific path. For example,

GET /foo/

wins over

/foo/

because the first specifies a method, but it loses to

GET /foo/bar

because the latter's path is more specific (it matches only "/foo/bar", 
while "/foo/" matches any path beginning "/foo").

Those three patterns make sense together:

GET /foo/bar match a specific GET request
GET /foo/   match any GET request beginning /foo
/foo/match a request with any 
method beginning /foo

But what about these two patterns:

GET /foo/
/foo/bar

The first pattern specifies a method, but the second has a more specific 
path. Which should win? Or should this combination be disallowed because 
it's too confusing? My question is, do any pairs of patterns like this show 
up in practice? And if so, which one should take precedence?

Thanks in advance for your help.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0b53f667-4ac2-4910-a49b-17a38e486de1n%40googlegroups.com.

[go-nuts] golang -tour- its possible to contribute on the translation to spanish , how I can do it?

[Jonathan L]

golang -tour- its possible to contribute on the translation to spanish , 
how I can do it?

https://go.dev/tour/welcome/2

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/735011f6-f58c-4111-905a-0178bbce8286n%40googlegroups.com.

[go-nuts] int64(math.Inf(+1)) != math.MaxInt64

[Jonathan Pearson]

I expected int64(math.Inf(+1)) == math.MaxInt64, but it does not.

In fact, these three values are equal:
int64(math.Inf(+1))
int64(math.Inf(-1))
math.MinInt64

This surprised me, and the language spec didn't clarify this specific 
behavior, so I wondered whether it was intentional. If so, why?

~Jonathan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3970aef1-8416-4102-bbd7-72033993e9b0n%40googlegroups.com.

[go-nuts] structured, leveled logging

['Jonathan Amsterdam' via golang-nuts]

If you're interested in logging, you may want to check out the discussion 
about a potential new standard library package for structured logging. 

https://github.com/golang/go/discussions/54763

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3c744c08-8341-44c6-b059-431feb5e99fbn%40googlegroups.com.

Re: [go-nuts] Is Go a security malware risk?

[Jonathan Reiter]

Hi there,

I agree with Holloway here, and raise a very specific point. If the
poster's fear is with a new language bringing additional polymorphism to
malware, I would say there are *far* easier ways to permute a binary and
thus make it resistant to either reversing or signature based detection.
Packing, fileless mechanisms, and cryptographic seeds all come to mind, and
none of them imply using Go. In fact, adding another language to the mix
only serves to complicate matters.

IMHO the trend in the field is less of Go being part of the malware supply
chain because of polymorphism, and more of its use because it is simpler to
write system (and server, in the case of C2) code. Happy to share some
sources on this topic if folks are interested in a deeper dive.

Best,
Jonathan

On Thu, Aug 25, 2022 at 1:47 AM Holloway Kean Ho 
wrote:

> Hi,
>
> I be very blunt here:
>
>1. What exactly you're trying to achieve by taking a very elaborated,
>crystal-clear, good-willed security-related article way out of its context
>with your thread title here and agitate some of the Go maintainers here?
>
> Why I'm asking:
>
>- AFAIK, behavior scanning technique was long implemented in their AV
>runtime detection (some time ago, comsumer product AV was requested to tone
>down such method because it took so much resources to the point where the
>CPU is too busy to the point of unsable) alongside the common signature
>pattern matching technique.
>- I still hear Go developers on Windows complaining about their AV
>blindly deleting their compiled Go binaries during their development.
>- The article specifically mention Go because Go had long achieved one
>of its 'ease of use' strength so it's not surprising that it will become a
>staple language for both good and maliciously motivated software in near
>future.
>- Security is about constant learning, exploring, testing (including
>outside the box thinking), and sharing. It's a habit and an attitude; not a
>job. Go, Rust, C, C++, POSIX Shell, etc are merely tools. In fact, if you
>comprehend the article correctly (2nd last paragraph), it implies that you
>should and shall acquire these new tools and then upgrade your arsenals
>ASAP collaobratively.
>- Security is a constant "cat chasing mouse" aspect. Sometimes the
>sword is better than shield; sometimes the other way round; sometimes some
>people misconfigured a pizza as a shield; sometimes you encounter manager
>brought a properly configured shield offline for the sake of "convinence"
>and "too much to learn". Given so many probability of disaster, the last
>thing is to actively denying innovation (as in birth of new tools like Go,
>Rust, etc) that builds better sword and shield.
>
> I believe you already have you answer from the get-go.  Peace.
>
> Regards,
> Holloway
>
> On Thursday, August 25, 2022 at 1:54:47 PM UTC+8 Amnon wrote:
>
>> I learned a few things from the article.
>> Apparently Go is an "unconventional language".  So Languages are divided
>> into "conventional" and "unconventional"
>> languages.
>> I know a few languages. Some are statically typed, some have dynamic
>> typing. Some are interpreted and some are compiled.
>> But I don't really know how one defines a conventional vs an
>> unconventional language, and how we distinguish between them,
>> and what its properties are.
>>
>> The other thing I learned was that Go is a relatively new language.
>> I was under the mistaken impression that Go has existed for quite a while
>> - for over a decade.
>> I thought that Go was first publicly launched in 2009 - an eternity ago
>> in the fast paced world
>> of software engineering. But perhaps the world of corporate security
>> software moves at a more
>> glacial pace, building systems and scanners which deal with languages
>> threats from decades ago. Perhaps their
>> definition of "new" is different from that of people in the rest of the
>> tech world. This may explain the ineffectiveness
>> of corporate security systems in preventing a whole series of devastating
>> ransomware attacks on high profile organisations.
>>
>> More seriously, I do agree with the conclusion of the article, that
>> security tools need to focus on the behaviour of software
>> rather than looking for signatures in a list of known pre-existing
>> malware.
>>
>> On Wednesday, 24 August 2022 at 10:15:43 UTC+1 Gopher-Insane wrote:
>>
>>> Thanks, everyone for your replies. This will really help.
>>>
>>> On Wednesday, 24 August 2022 at 06:28:

[go-nuts] Bring back slices.BinarySearchFunc with a predicate

[Sudhir Jonathan]

The earlier method signature for slices.BinarySearchFunc was very useful:

It was of the form 
```
slices.BinarySearchFunc(array, func(e T) bool)
```
which returned the smallest index at which predicate would return true. 

This was incredibly useful to do inequality operation binary searches  - 
like find the smallest index in a sorted slice where the element was 
greater than this (helps figure out the index of the last repeat of an 
element in the sorted slice). 

I understand the new method is true-er to its name, but can we bring the 
old one back as well, maybe as slices.BinarySearchPredicate ?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f5f8c4a8-56da-4f00-a43b-20015828fdb5n%40googlegroups.com.

[go-nuts] Re: Alternatives to wrapping errors

[Jonathan Hall]

Yes, of course I'm quite familiar with Go 1.13's error capabilities.  
github.com/pkg/errors is still useful when one wants to attach stack traces 
to errors.

But this leaves my question open:  What are alternatives to wrapping 
errors? (Other than passing around errors with no semantic meaning, as was 
the case before wrapping was widespread)

On Thursday, December 23, 2021 at 8:51:20 PM UTC+1 Kevin Chowski wrote:

> Have you seen https://go.dev/blog/go1.13-errors?
>
> If one wants to use error unwrapping, these days generally it is suggested 
> to use the functionality from the standard package "errors" (or fmt.Errorf) 
> rather than some third-party package. That way everyone does it the same 
> way, making third-party packages more composable by default.
>
> I personally wrap errors with fmt.Errorf and the %w verb when I want to 
> add additional context to some error I received, and the root cause of why 
> my function failed is *precisely* the same as the 'error' value I received. 
> This is less often than I used to think, and it is definitely a maintenance 
> risk when this error comes from another package: if that package changes 
> what error type it returns, that may break some other part of my code. 
> (that risk is perhaps one reason why folks choose not to wrap errors by 
> default, though note that errors from Go's stdlib are less likely to change 
> over time than some random third-party library.)
>
> In general, I prefer to wrap errors that come from a package that I own 
> (again assuming the root cause is exactly the same AND I want to add some 
> annotation), and prefer not to wrap errors that come from a package owned 
> by someone else. But neither are hard rules for code I write or review.
>
> One last thought is: if you never unwrap an error, there are fewer good 
> reasons to ever wrap them. If you want to unwrap them, then it obviously 
> starts to make sense to wrap some :)
>
> On Thursday, December 23, 2021 at 5:59:22 AM UTC-7 fli...@flimzy.com 
> wrote:
>
>> I was recently catching up on the latest state of the 
>> github.com/pkg/errors package (https://github.com/pkg/errors/issues/245), 
>> when I noticed that Dave Cheney said:
>>
>> > I no longer use this package, in fact I no longer wrap errors.
>>
>> I'm curious what approach Dave uses now, but unless/until he writes on 
>> the topic, I'm also curious what other approaches people use for clean and 
>> cohesive error handling and reporting.
>>
>> If you don't wrap errors, how do you ensure meaningful error handling and 
>> reporting in your application?
>>
>> Thanks,
>> Jonathan
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a3afcdd9-3dd5-4bb6-84ef-8b05667519a0n%40googlegroups.com.

[go-nuts] Alternatives to wrapping errors

[Jonathan Hall]

I was recently catching up on the latest state of the github.com/pkg/errors 
package (https://github.com/pkg/errors/issues/245), when I noticed that 
Dave Cheney said:

> I no longer use this package, in fact I no longer wrap errors.

I'm curious what approach Dave uses now, but unless/until he writes on the 
topic, I'm also curious what other approaches people use for clean and 
cohesive error handling and reporting.

If you don't wrap errors, how do you ensure meaningful error handling and 
reporting in your application?

Thanks,
Jonathan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5072db45-ea09-45f9-a0ff-05457bda6dd3n%40googlegroups.com.

[go-nuts] Go Boring release schedule

[Jonathan Yu]

Hey there,

Go 1.17 was released last week (Aug 16th), but it appears the corresponding
build of Go + Boring Crypto is not available yet (checking the Google Cloud
Storage bucket as well as Docker Hub). Does anyone know if these releases
typically track the main upstream Go closely, or if releases lag some
period of time?

I understand some folks might be on summer vacation, so wanted to check if
there's an expected publication date for this so I can plan accordingly. :)

Thanks,

Jonathan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMDxSEg4rKBv2DJRHsWPRT5DPLaY672rZzU%2BPBnVnR_ZdFW9LQ%40mail.gmail.com.

[go-nuts] GopherJS 1.16 released!

[Jonathan Hall]

After lagging behind Go for about 2 years (since version 1.12), GopherJS 
1.16.0+go1.16.3 
 has 
been released with Go 1.16 support!

GopherJS compiles Go code to pure JavaScript code (not WebAssembly). It’s 
main purpose is to give you the opportunity to write front-end code in Go, 
which will still run in all browsers, while allowing integration with 
existing JavaScript libraries.

This comes on the heels of a recent reorganization of the GopherJS 
community, and a resurgence of activity and interest in the project.

You can try out GopherJS without installing it by using the GopherJS 
playground .

GopherJS 1.16 is still lacking a couple important features of modern Go, 
which are on the roadmap. Most notably:

   - Go modules are not yet supported. You can still build with GOPATH 
   mode, or use a workaround 
   .
   - Go 1.16’s embed directive is still forthcoming.

For these features, as well as the upcoming support for Generics in Go 
1.17, we would gladly welcome volunteers from the community!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/024dd6c8-f1e6-43cf-a96b-4de376699563n%40googlegroups.com.

Re: [go-nuts] Finding error type for `errors.As` and `errors.Is`

[Jonathan Amsterdam]

You can write such a function yourself. For that reason and since it would 
be rarely useful, I don't think it's likely to become part of the standard 
library.

On Thursday, April 1, 2021 at 9:02:34 AM UTC-4 Michael Schaller wrote:

> Roger, I think you slightly misunderstood me. ;-)
>
> It is true that `As` and `Is` methods can be used to allow `errors.As` and 
> `errors.Is` to handle error types that aren't actually in the error chain.
>
> However my question was if an `errors.Chain` function which returns 
> details about the error types and values in the error chain would be a 
> worthwhile addition to Go's `errors` package.
>
> On Wednesday, March 31, 2021 at 7:33:32 PM UTC+2 rog wrote:
>
>> On Wed, 31 Mar 2021 at 18:05, 'Michael Schaller' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I often encounter deep error chains where errors are wrapped across 
>>> several Go packages and that makes it often hard to find a usable error 
>>> type to use with `errors.As` or `errors.Is`.
>>>
>>> Could it make sense to add an `errors.Chain` function to Go that returns 
>>> a slice with tuples of error type (reflect.Type) and the respective error?
>>>
>>
>> Unfortunately that's not possible in general because errors in the change 
>> can implement their own `As` and `Is` methods, so an error can appear
>> to have some type T in the chain (i.e. errors.As(new(T)) returns true) 
>> without *actually *having that type in the chain.
>>
>> For example: https://play.golang.org/p/-IAKMrD8FlG
>>
>> It's a shame in my view, but that's what we've got.
>>
>>   cheers,
>> rog.
>>
>>
>>> Quick example:
>>> https://play.golang.org/p/hDW0_6P7O2Y
>>>
>>> Best,
>>>
>>> Michael
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/acab291d-21bc-4c84-a19a-7f9901cc8035n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8bd84b0b-2633-4d2e-8628-a23712e18122n%40googlegroups.com.

Re: [go-nuts] [Macos/Apple M1] HTTP client requests to ".local" domain adds 5 seconds overhead

[Jonathan Hedrén]

Thanks! I added the IPv6 loopback address to all my host names in 
/etc/hosts (i.e. "::1 mydomain.local") and it now works as expected. 

I guess Go's DNS resolver was timing out at the first attempt, that's why I 
consistently had that 5 second delay.

torsdag 1 april 2021 kl. 07:40:10 UTC+2 skrev Shulhan:

> On Wed, 31 Mar 2021 01:47:43 -0700 (PDT)
> Jonathan Hedrén  wrote:
>
> > I've set up a development environment on my MacBook Pro M1 (running
> > Big Sur 11.2.3, Go 1.16.2) with a number of small Go/.Net HTTP APIs
> > that are communication with each other. To replicate our production
> > infrastructure I've set up /etc/hosts with ".local" domains pointing
> > to 127.0.0.1. An nginx server then proxies the requests to the APIs.
> > A self signed certificate is used for https.
> > 
> > Whenever an HTTP request is sent from a Go application to any of the 
> > ".local" APIs, 5 seconds are added to the response time. This delay
> > is not added when I use a browser to make the request, neither if I
> > call an external address (for example google.com) or "localhost" from
> > the Go code. It only happens when I use http.Client to request a
> > ".local" domain and the behavior is consistent. 
> > 
> > I've searched the Go standard library for a "5 * time.Second" and
> > found it only in a few places, including src/net/dnsconfig_unix.go so
> > I guess it's related to the name resolution.
> > 
> > Anyone got an idea about what's wrong and how it can be fixed? 
> > 
> > /Jonathan
> > 
>
> Previous discussion on this subject:
>
> https://groups.google.com/g/golang-nuts/c/BuMYgqMCw8I/m/pIAhmNIWBQAJ
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5f0fbf95-20b3-4cac-897d-5af1cc7c6bb4n%40googlegroups.com.

[go-nuts] [Macos/Apple M1] HTTP client requests to ".local" domain adds 5 seconds overhead

[Jonathan Hedrén]

I've set up a development environment on my MacBook Pro M1 (running Big Sur 
11.2.3, Go 1.16.2) with a number of small Go/.Net HTTP APIs that are 
communication with each other. To replicate our production infrastructure 
I've set up /etc/hosts with ".local" domains pointing to 127.0.0.1. An 
nginx server then proxies the requests to the APIs. A self signed 
certificate is used for https.

Whenever an HTTP request is sent from a Go application to any of the 
".local" APIs, 5 seconds are added to the response time. This delay is not 
added when I use a browser to make the request, neither if I call an 
external address (for example google.com) or "localhost" from the Go code. 
It only happens when I use http.Client to request a ".local" domain and the 
behavior is consistent. 

I've searched the Go standard library for a "5 * time.Second" and found it 
only in a few places, including src/net/dnsconfig_unix.go so I guess it's 
related to the name resolution.

Anyone got an idea about what's wrong and how it can be fixed? 

/Jonathan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6544c7eb-f7ec-4056-b9a2-da03bfad5ea4n%40googlegroups.com.

Re: [go-nuts] Analysis check for leaked pointers to loop variable address

[Barisere Jonathan]

That's correct. I've found that it's most often a mistake when working with 
slices. But for maps, there is some use for it, such as relying on maps 
being unordered to select random values from the map, although there should 
be a better way to do that.
An analysis check for this should produce a warning. I'm betting that since 
it's an error in most of the cases I've come across, a warning will be 
useful most of the time.

On Monday, March 15, 2021 at 8:34:14 AM UTC+1 Jan Mercl wrote:

> On Mon, Mar 15, 2021 at 3:03 AM Barisere Jonathan 
>  wrote: 
>
> > I think this mistake can be caught by code analysis tools, but I don't 
> know of any that catches these. 
>
> IMO the problem is that while sometimes it's a mistake, in some other 
> cases it is not and it is perfectly good, reasonable code. Next to 
> impossible for a machine to decide which case it sees. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/dffb2987-2c48-4d21-af0d-18a44ac343f9n%40googlegroups.com.

[go-nuts] Analysis check for leaked pointers to loop variable address

[Barisere Jonathan]

Hello everyone.

I have a question about a common programming error I have made several 
times. It regards the use of a pointer to a loop variable outside of the 
loop. Basically, we want to convert a slice, map, or channel of items (the 
source sequence) into a map, slice, or channel of pointers to respective 
items in the source sequence. But, rather than point to the actual values, 
we point to the loop variable.
I have written some code in a GitHub gist to demonstrate this mistake 
. I 
think this mistake can be caught by code analysis tools, but I don't know 
of any that catches these. If there is any, please let me know so that I 
can save my future self some unnecessary trouble. If there isn't, how can I 
make one (probably add it to vet)?
Here's the code sample, if you prefer to read it all here.


// escape_test.go

package main_test

import (
"testing"
"testing/quick"
"unsafe"
)

func all(xs []*int, f func(x *int) bool) (result bool) {
result = true
for _, v := range xs {
result = result && f(v)
}
return result
}

func Test_references_to_loop_variable_outside_the_loop_have_same_value(t 
*testing.T) {
f := func(xs []int) bool {
var loopVariableAddress uintptr
var zeroOfUintptr uintptr
var copies = make([]*int, 0, len(xs))
for _, x := range xs {
if loopVariableAddress == zeroOfUintptr {
// Store the loop variable's address for later comparison.
loopVariableAddress = uintptr(unsafe.Pointer())
}
// Copy the address of x into a slice.
copies = append(copies, )
// The append statement above is most likely a mistake.
// We probably mean
// copies = append(copies, [index]);
// assuming `index` is the ignored loop index.
}
return all(copies, func(x *int) bool {
// All values in `copies` are the same pointer address.
return uintptr(unsafe.Pointer(x)) == loopVariableAddress && *x 
== *copies[0]
})
}

if err := quick.Check(f, nil); err != nil {
t.Fatal(err)
}
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cfbc843b-2acf-4440-81d2-01ab68a6628bn%40googlegroups.com.

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

[Jonathan Amsterdam]

I changed the encoding so that the previous generated code is no longer 
necessary. Encoded data now carries all the information needed to decode 
struct fields correctly, even if fields have been added and reordered.


On Sunday, January 24, 2021 at 8:29:58 AM UTC-5 Jonathan Amsterdam wrote:

> Thanks for the suggestions. I created https://github.com/jba/codec/pull/1 
> to address them. You can comment in more detail there if you'd like.
>
> On Wed, Jan 20, 2021 at 12:13 PM roger peppe  wrote:
>
>> On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam  
>> wrote:
>>
>>> The encoding scheme is described briefly in the README[0] and the 
>>> code[1].
>>>
>>> To answer your two specific questions, interfaces are represented as a 
>>> pair (typeNumber, value) where typeNumber maps to a registered type. (Like 
>>> gob, types must be registered.) Structs are represented as: startCode 
>>> (fieldNumber value)* endCode. The field numbers are assigned by the 
>>> generator.
>>>
>>
>> It might be good to be more explicit about how the field numbers are 
>> assigned. From a brief experiment, it seems like there's not a deterministic
>> relationship between a struct and its wire representation, and instead 
>> the generated field numbers are taken from the generated code file
>> when it's present. So ISTM that any user of this must be very careful to 
>> preserve that file, and realise that it's not OK to generate
>> the codec code for a type independently.
>>
>> I'd also suggest that it would be good to fully document the syntax and 
>> explain the trade-offs of this format and when
>> it might or might not be appropriate to use.
>>
>> One other question: how are the type numbers maintained as stable 
>> entities over time?
>>
>>   cheers,
>> rog.
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ad1d2cc1-acfc-4278-93b7-05e09bb8b8aan%40googlegroups.com.

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

[Jonathan Amsterdam]

Thanks for the suggestions. I created https://github.com/jba/codec/pull/1
to address them. You can comment in more detail there if you'd like.

On Wed, Jan 20, 2021 at 12:13 PM roger peppe  wrote:

> On Wed, 20 Jan 2021 at 13:31, Jonathan Amsterdam 
> wrote:
>
>> The encoding scheme is described briefly in the README[0] and the code[1].
>>
>> To answer your two specific questions, interfaces are represented as a
>> pair (typeNumber, value) where typeNumber maps to a registered type. (Like
>> gob, types must be registered.) Structs are represented as: startCode
>> (fieldNumber value)* endCode. The field numbers are assigned by the
>> generator.
>>
>
> It might be good to be more explicit about how the field numbers are
> assigned. From a brief experiment, it seems like there's not a deterministic
> relationship between a struct and its wire representation, and instead the
> generated field numbers are taken from the generated code file
> when it's present. So ISTM that any user of this must be very careful to
> preserve that file, and realise that it's not OK to generate
> the codec code for a type independently.
>
> I'd also suggest that it would be good to fully document the syntax and
> explain the trade-offs of this format and when
> it might or might not be appropriate to use.
>
> One other question: how are the type numbers maintained as stable entities
> over time?
>
>   cheers,
> rog.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEymQsQ%3D4WkteR1t6o5TXfzp0egR%3DvsGii8On_mKBU%2B_YRM%2BfA%40mail.gmail.com.

Re: [go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

[Jonathan Amsterdam]

The encoding scheme is described briefly in the README[0] and the code[1].

To answer your two specific questions, interfaces are represented as a pair
(typeNumber, value) where typeNumber maps to a registered type. (Like gob,
types must be registered.) Structs are represented as: startCode
(fieldNumber value)* endCode. The field numbers are assigned by the
generator.

The schema is implicit. The model is protobufs, where there is just enough
information in the wire protocol to skip values, but you need something
external to interpret types and struct field numbers.


[0] https://github.com/jba/codec#encoding-scheme
[1] https://github.com/jba/codec/blob/v0.3.1/codecapi/codecapi.go#L200


On Tue, Jan 19, 2021 at 10:50 AM roger peppe  wrote:

> This is interesting, thanks! Is there a full description of the encoding
> somewhere? (e.g. how are structs represented? what about interface values,
> etc? is the schema implicit or sent on the wire?)
>   cheers,
> rog.
>
> On Tue, 19 Jan 2021 at 14:59, Jonathan Amsterdam 
> wrote:
>
>> Uses code generation for fast encoding and decoding of Go values to
>> bytes. Handles sharing and cycles too.
>>
>> https://pkg.go.dev/github.com/jba/codec
>>
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/2cc71201-ddbf-4524-88ba-7d0875072d80n%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/2cc71201-ddbf-4524-88ba-7d0875072d80n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEymQsRAJKsu2Fe5PwHvTyYW2d1L7ksiJnGfcmPQDohfXtw-yg%40mail.gmail.com.

[go-nuts] [ANN] github.com/jba/codec, a fast encoder for Go

[Jonathan Amsterdam]

Uses code generation for fast encoding and decoding of Go values to bytes. 
Handles sharing and cycles too.

https://pkg.go.dev/github.com/jba/codec


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2cc71201-ddbf-4524-88ba-7d0875072d80n%40googlegroups.com.

[go-nuts] [ANN] templatecheck: type-checking Go templates

[Jonathan Amsterdam]

The github.com/jba/templatecheck package[0] can validate field references 
and other operations of a text/template or html/template in tests or during 
program startup. It also works for github.com/google/safehtml/template[1].

[0] https://pkg.go.dev/github.com/jba/templatecheck 
[1] https://pkg.go.dev/github.com/google/safehtml/template

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a517b247-50d4-40a3-a191-69d8c5c34e80n%40googlegroups.com.

[go-nuts] Is this behavior by textproto.Writer.DotWriter correct?

[Jonathan]

When a DotWriter is created and closed without any write being done, the 
buffer contains a CR/LF . CR/LF. When a DotWriter is created and closed 
with a single write of an empty line, the buffer also contains CR/LF . 
CR/LF. See:
https://play.golang.org/p/ScXaRPBH7vI

This seems wrong to me.  If it isn't I think the documentation should note 
this.

Jonathan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/689bbe79-e9f4-472e-8391-567c767a6e11n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Jonathan Gerber]

As someone who has spent a LOT of time in Rust, I really miss generics in 
Go (Conversely, i miss the simplicity of Go. My personal favorite, 
imaginary language would probably be  Go + Generics + Sum Types and 
destructuring) and so I am really excited to see this taking shape. 

That being said, here are some things that I personally think are less than 
ideal (first world problems eh?):

1) Of the enumerated omissions, the ones that I think are really 
unfortunate are, in order of importance, from my perspective: 

   - No operator methods & no adapters - Doesn't this make generic types 
   sort of second class?. I think these features would be an elegant addition 
   to the language but I assume that there is a reason for their omission. 
   - No support covariance or contravariance. Maybe I am on shaky ground in 
   terms of my understanding but doesn't this mean, for instance, that if I 
   have two interfaces, Foo and Bar, and a third composite interface, FooBar, 
   which consists of Foo and Bar, that a function with a generic parameter T 
   constrained by Foo would not accept a type that implements FooBar? If i am 
   incorrect, where does this come into play?
   - No support for variadic type parameters. Rust gets around this with 
   hygienic macros and meta-programming. I am not a big fan of the level of 
   complexity/quirkiness involved with working around the lack of variadics in 
   Rust. I hope to see them in Generics in Go one day. Otherwise, you will 
   probably end up api bloat full of functions differing only in the number of 
   parameters supported.

2) I don't see syntax for directly applying multiple constraints to a 
generic type. Is this achievable only via interface composition? 
3) And something I glossed over during the first reading, but is a bit sad 
- Methods may not take additional type arguments. 

Also, in the area of ergonomics, here are some thoughts:
1) Allow for separating out generic type declarations from constraints. 
Rust allows you to split type parameter declaration from type constraints 
via an optional `where` keyword which comes right before the body of the 
entity. This is very helpful for readability, especially given complex 
constraints.
2) I personally don't think allowing multiple types to share a constraint 
is worth not allowing unbounded types without the bulky "interface{}" type. 
Is there some other simpler syntax that could be considered? Would a simple 
{} be a parsing nightmare? What about '_' ?  Something like `func Something 
(type T _, U SuperUseful ) (a T, b U){...}` ?
On Monday, August 10, 2020 at 9:46:44 AM UTC-7 3cl...@gmail.com wrote:

> I am trying to add my 2 cents here.
>
>
> I am sorry if my opinions have been mentioned.
>
> I personally prefer Round Brackets (parentheses). It is not about 
> readability on symbols, but the way how I understand the logic of Type 
> Parameters.
>
>
>
> I see Type Parameters as a way to describe how to "instantiated" a 
> Declaration (Func/Struct) for being used.
>
> Considering the case of https://go2goplay.golang.org/p/JjA67w8ZvFu , the 
> func `min` is asking for a `type` argument to be specified so it can work 
> properly. Which means it is valid to code line L19 `m := min(int)` to 
> initialize the func `min` with type `int`. 
>
> If we try to read a Type Parameterized func declared in this way, it means 
> the func `min` will first take a `type` argument to initialize it. then the 
> second Round Brackets `(...)` put the arguments to call the func. 
>
> However with Square Bracket, L19 of the case will not work, cause `m := 
> min[int]` would mean taking an element from `min` on index `int`. (sure, 
> min here is a Type Parameterized Func, not a slice)
>
>
>
> On the other hand, we can take an analogy of how Functional Programming 
> (FP) works with funcs with multi parameters. (correct me if I am wrong). 
>
> In FP, when a function take two arguments, say `f(a int, b string)`, it's 
> actually interpreted as "A function called `f`, it will first take an 
> argument `a` with type `int`, and return a function f2 which keep a copy of 
> `a` and takes an argument `b` with type `string`". 
>
> An example in Go is following:
>
> ```go
> func concat(a int, b string) string {}
> ```
>
> is equal to
>
> ```go
> func concat(a int) (func( b string) string){
> return func(b string) {
> a := a
> // DO THE ACTUAL WORK
> return
> }
> }
> 
> and when calling `concat()` with `concat(1, "2")`, is actually 
> `concat(1)(2)` or `tmp := concat(1); result := tmp(2)`
>
>
> Taking this analogy back to the original Type Parameters proposal. We can 
> think of a Type Parameterized func has to be called with a `type` being 
> specified. The Type Parameterized func will return a typed version of it. 
> Then we call it with the actual argument(s). 
>
> With Square Brackets, it cannot be interpreted in this way IMO as the 
> syntax is inconsistence. It only make it easier to read for 

Re: [go-nuts] where is temp file created by http server

[Jonathan Reiter]

See the multipart function definition. Line 86 deals with the actual temp
file writes.

https://golang.org/src/mime/multipart/formdata.go?s=3015:3047#L34

Do note that under certain conditions, a multipart form might hold on
closing and deleting the multipart files in temp. Debugging async code and
judicious use of RemoveAll can help with this.

https://golang.org/pkg/mime/multipart/#Form.RemoveAll



On Thu, Jul 16, 2020 at 5:59 PM hao dong  wrote:

> thx. Can you help me find the link or doc which describe the detail of "
> removed once the request finished" ?
>
> On Thursday, July 16, 2020 at 7:32:06 PM UTC+8, Jesper Louis Andersen
> wrote:
>>
>> They will be removed once the request finishes. The way to access them is
>> usually by the FormFile method on *http.Request or to create a multipart
>> reader and break it out yourself.
>>
>> The reason the latter is interesting is because it can avoid storing data
>> you are not prepared to handle.
>>
>> On Thu, Jul 16, 2020 at 12:44 PM hao dong  wrote:
>>
>>> As I have learned, http server will store user-upload file on disk when
>>> its size exceed 32MB.
>>> I read the source code, and find out the large file to store in
>>> os.TempDir(), however, after uploading a large file, I can not find the
>>> file in the temp dir.
>>> Cloud someone enlight me, where is the temp file ?
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/0232db86-9bfb-42ae-b24b-49ea57a222ado%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> J.
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/53d14db3-1c23-43f0-9613-1c7ac7645e96o%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAC41hdMpgh2yZ%2BhT2LSMoUzcb-4ANT6BTkX5NS23fTdr9fn%2BFQ%40mail.gmail.com.

[go-nuts] Re: decode unknown CBOR type with set of known types

[Jonathan Amsterdam]

My first question would be, is the type encoded into the CBOR blob somehow? 
Like by a tag? 

If structs are encoded as maps, with no type information, then the input 
doesn't have enough information to do what you want. How could the blob 
(using JSON notation)

   {"X": 1, "Y": 2}

know whether it should decode into

type Point struct { X, Y int}

or 

type Chromosome {X, Y int}

?

You have to encode the type somehow. If you control the encoding process 
and you're encoding a fixed set of types that you want to distinguish at 
decode time,
you can do something like this:

  type (
  This ...
  That ...
  TheOther ...

  Thing struct {
 This *This
 That *That
 TheOther *TheOther
 }
 )

To encode a `This` named `t`, actually encode `Thing{This: }`. When you 
decode that into a `Thing`, only the `This` field will be non-nil, so you 
know you've got a `This`.

(Disclaimer: I know this technique works with the encoding/json package; I 
can't guarantee it works with the cbor package you're using because I'm not 
familiar with it,
but if it behaves like encoding/json, you should be OK.)

On Wednesday, July 8, 2020 at 3:44:36 PM UTC-4, David Stainton wrote:
>
>
> Greetings,
>
> Similar questions have been asked in the past and I've read those posts... 
> and I believe I'm asking something different here.
>
> I'm using length prefixed CBOR over unix domain socket as my wire format. 
> However the reader doesn't known which CBOR type it needs to decode.
> I'd like a mechanism similar to the golang switch type assertion where a 
> known set of types are specified.
>
> Before you go and tell me to use the empty interface let me explain that 
> certainly this works:
>
> // "github.com/fxamacker/cbor"
> var v interface{}
> err = cbor.Unmarshal(out, )
>
> It works for some definitions of "works". It doesn't tell me what type it 
> is but it does allow me to access each struct field by name in the map of 
> type: map[interface {}]interface {}
>
> The reason this is not good enough is that it doesn't concretely tell me 
> the type!
> Of course I could go ahead and add a struct field called TypeName and set 
> it's value to a string encoding the name. But that feels wrong and I'd feel 
> bad after writing it.
>
> I've also tried to ask this question on a ticket here:
> https://github.com/fxamacker/cbor/issues/241
>
> Is the least incorrect solution to iteratively try cbor.Unmarshal with all 
> the types in the known set of possible types until one of them works?
>
> Certainly this problem isn't specific to CBOR. Am I asking the question 
> incorrectly here?
>
>
> Sincerely,
> David
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/019fb798-f282-451d-947c-79a7c1bc2b98o%40googlegroups.com.

Re: [go-nuts] godoc.org pkg.go.dev banner feedback

['Jonathan Amsterdam' via golang-nuts]

Fixed in production. The links work now.

On Monday, July 6, 2020 at 12:47:34 PM UTC-4 Julie Qiu wrote:

> Thanks for letting us know! This looks like a bug - we'll look into it. I 
> filed an issue here: https://github.com/golang/go/issues/40071
>
>
> On Thursday, July 2, 2020 at 12:00:57 PM UTC-4, Russ Cox wrote:
>
>> Thanks for the feedback Jan. Google is on an extended holiday weekend for 
>> the US holiday but we'll definitely chase this down when people are back.
>>
>> Best,
>> Russ
>>
>>
>> On Thu, Jul 2, 2020 at 11:38 AM Jan Mercl <0xj...@gmail.com> wrote:
>>
> godoc.org displays packages from the domain modernc.org just fine. It
>>> also adds a banner sayings, for example at
>>> https://godoc.org/modernc.org/cc/v3
>>>
>>> "Pkg.go.dev is a new destination for Go discovery & docs.
>>> Check it out at  pkg.go.dev/modernc.org/cc/v3 and share your
>>> feedback."
>>>
>>> However, clicking that link (ie. https://pkg.go.dev/modernc.org/cc/v3)
>>> is a 404. In fact, all modernc.org packages I have tried just minutes
>>> ago, about 20 of them, are 404.
>>>
>>> The feedback is: Please either fix pkg.go.dev or do not put the banner
>>> in godoc that does not work and may confuse package users. FTR, it
>>> seems all the modernc.org packages are still present in the pkg.do.dev
>>> search index and I remember that the packages used to be shown there.
>>> I have not asked anyone to remove them, so I suppose some glitch must
>>> have happened somewhere.
>>>
>>> I have tried to follow the instructions found here:
>>> https://go.dev/about#adding-a-package but I see no change. However,
>>> it's not clear if there's some delay involved between triggering the
>>> process and the results being available. I suggest adding that
>>> particular piece of information to the instructions.
>>>
>>> I'd appreciate a reply from anyone having insight into this. Thanks in 
>>> advance.
>>>
>>> -- 
>>> 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 golan...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAA40n-Uaq651HywVteubB6CCre_UbfXofPcOZaESJ3V_y1gswA%40mail.gmail.com
>>> .
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/08b4baf4-5e96-4010-8ad4-4e0ea9e41f95n%40googlegroups.com.

[go-nuts] Re: go.pkg.dev missing golang packages

[Jonathan Amsterdam]

You can open an issue on the Go issue tracker. Use this 
link: https://golang.org/s/discovery-feedback.

I filed https://golang.org/issue/39894.

On Saturday, June 27, 2020 at 1:20:15 PM UTC-4, Steve Roth wrote:
>
> I understand that some Go package documentation is not documented on 
> go.pkg.dev for licensing reasons.  However, I would not have expected 
> that packages maintained by the Go team itself would have such problems.  
> Yesterday I discovered, for example, that the documentation for 
> github.com/golang/freetype is not shown on go.pkg.dev.
>
> Is it a reasonable expectation that anything under github.com/golang 
> should be documented on go.pkg.dev?  And if so, what is the proper path 
> to report this issue?
>
> Regards,
> Steve
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a63e12b7-2633-4c00-acc8-8a5aa36aea57o%40googlegroups.com.

Re: [go-nuts] Using context package for goroutines cancellation is quite verbose

[Jonathan Amsterdam]

Typically, a network communication system, like gRPC for example, will 
accept contexts for network calls and turn context done-ness into an error. 
The typical signature of an RPC-backed function is

func(context.Context, req *Request) (*Response, error)

If the context times out or is cancelled, a good RPC library will return 
from this call immediately with a non-nil error. So context done-ness 
checking is just part of ordinary error checking.

I'm not sure how you're mapping the RPCs to channels. If you're doing

res, err := RPC(ctx, req)
if err != nil { return ... }
ch <- res

then you indeed have a problem: you'll need another check whenever you 
receive from the channel. But if you're doing

res, err := RPC(ctx, req)
ch <- rpcResult{res, err}

then receivers don't have to check ctx.Done, but of course they do have to 
check the error:

result <- ch
if result.err != nil { ...}
// use result.res
 
Channels are a bit awkward either way, so for the Google Cloud client 
libraries we use an iterator pattern (
https://github.com/googleapis/google-cloud-go/wiki/Iterator-Guidelines).

On Tuesday, June 9, 2020 at 8:04:21 AM UTC-4, Yegor Roganov wrote:
>
> Thanks Ian, it's nice to know that we're using Go correctly.
>
> I agree that more code doesn't really matter, and I think I'd be 
> completely fine with this situation had there been a vet check that ensured 
> that no selects are forgotten.
> Let's see if generics change something in this area.
>
> On Monday, June 8, 2020 at 10:46:05 PM UTC+3, Ian Lance Taylor wrote:
>>
>> On Mon, Jun 8, 2020 at 9:59 AM Yegor Roganov  wrote: 
>> > 
>> > My team is developing a cloud-based data processing application, and a 
>> large bulk of the application's job is doing network calls to other 
>> services. 
>> > Go's goroutines and channel-based communication are an excellent fit, 
>> but in order for the application to be able to properly shut down, 
>> > simple construct of sending to a channel `myChan <- value` needs to 
>> actually be something like: 
>> > 
>> > ``` 
>> > 
>> > select { 
>> > case myChan <- value: 
>> > case <-ctx.Done(): 
>> >return ctx.Err() 
>> > } 
>> > 
>> > ``` 
>> > 
>> > As you see, a simple one line construct needs to be replaced with a 
>> select on context.Done EVERYWHERE. 
>> > My two gripes with this situation are: 
>> > 
>> > 1) It's more code and "clutter" which makes code less clear 
>> > 2) It's easy to forget to do a select on context.Done, and then an 
>> application is unable to shut down. 
>> > 
>> > Am I doing something wrong? Does someone relate with me? 
>>
>> You are not doing anything wrong, and, you're right: it's more code. 
>>
>> In general, Go prefers code to be explicit rather than implicit, so I 
>> don't really agree that this makes the code less clear.  I think that 
>> this code is clear to anybody who knows Go, and with more experience 
>> it becomes fairly idiomatic. 
>>
>> But you're absolutely right that it's easy to forget to do a select. 
>>
>> Personally I think that this is an area where generics can help.  For 
>> example, from the design draft published last year, see 
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-contracts.md#channels
>>  
>> .  I think the right step here is going to be see how generics can 
>> help with these common patterns before trying other approaches.  I 
>> acknowledge that that is a slow process. 
>>
>> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de39eb18-2188-4236-ac33-6ec9109ce68fo%40googlegroups.com.

Re: [go-nuts] McAfee and the module cache on WSL: rename : permission denied

[Jonathan Reiter]

I don't think McAfee ENS officially supports WSL. At least that was the
case in 2018 when I last tried.

This would probably be evident in its labelling WSL /tmp writes as the
beginnings of an attack - you could always check your scan logs (at
%ProgramData%\McAfee\Endpoint Security\Logs) to see what is actually
happening - if this is a blacklisted directory, a rule firing, or if EDR is
picking up the sketchy behavior.

Feel free to raise a ticket to support on this topic - there's probably an
active community internal to McAfee who would love to get more momentum for
WSL support.

Some potentially dated sources on this topic:
1. ENS log manifest

2. ENS lack of support for WSL

3. A rather interesting article

which spells out why WSL might not be well supported, i.e. it has the
tendency to be used for fileless attack behaviors.

Hope this helps!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAC41hdON9_x54Fe6Yso8hd97%3DKCQ3Z6GRkfFjkwH6mB-Y5C2pQ%40mail.gmail.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

You're absolutely right. I just meant that the tokenizer interface wouldn't 
be completely replaced. There are still some corner cases where it will be 
necessary.


On Friday, August 9, 2019 at 11:41:17 PM UTC+2, burak serdar wrote:
>
> On Fri, Aug 9, 2019 at 3:32 PM Jonathan Hall  > wrote: 
> > 
> > I think you're right that most people are frustrated by the encoder, but 
> as I mentioned in another message just a bit ago, the same fundamental 
> problem exists with decoder, and for certain workloads, I believe it should 
> be solved. 
> > 
> > Having said that, I think tackling the writer first definitely makes the 
> most sense. 
> > 
> > With the decoder, at least it's possible, although terribly cumbersome, 
> to cobble together a solution with the tokenizer interface of json.Decoder. 
> And truth be told, my proposal wouldn't really elminate the use of the 
> tokenizer interface--but it would make it possible to use it on a burried 
> type (i.e. within a UnmarshalJSONStream() method), to achieve the benefit 
> of stream reading. 
>
> It may not be terribly cumbersome, and may not need the tokenizer 
> interface. I have a json streaming library (streaming in the sense 
> that multiple json docs one after the other, not one large doc) based 
> on the std encoder/decoder, and something like that can be developed 
> to deal with large json docs. 
>
> https://github.com/bserdar/jsonstream 
>
>
>
>
> > 
> > 
> > 
> > On Friday, August 9, 2019 at 10:17:41 PM UTC+2, burak serdar wrote: 
> >> 
> >> On Fri, Aug 9, 2019 at 2:10 PM Robert Engels  
> wrote: 
> >> > 
> >> > I'm sorry, maybe I didn't understand your original concern. There is 
> an example of doing stream based processing in the json package (using 
> Decoder). 
> >> > 
> >> > How is this not sufficient? 
> >> > 
> >> > The only problem I see with it is that it doesn't allow error 
> correction/continuation, but in the modern world that seems rather rare (or 
> very difficult to do well). 
> >> 
> >> I was thinking similarly and after reading those github issues, it 
> >> looks like the main problem is with Encoder, and not with Decoder. 
> >> Encoder's problem can be solved by providing an unbuffered output 
> >> option that directly writes to the io.Writer. 
> >> 
> >> I like the idea of stream-friendly marshaler/unmarshaler interfaces. 
> >> 
> >> > 
> >> > -Original Message- 
> >> > From: Jonathan Hall 
> >> > Sent: Aug 9, 2019 11:00 AM 
> >> > To: golang-nuts 
> >> > Subject: Re: [go-nuts] RFC for opt-in streaming support in 
> encoding/json package 
> >> > 
> >> > An interesting observation. 
> >> > 
> >> > Although in a sense, we already have the decoding half of that 
> low-level streaming API exposed by way of the `json.Decoder` type. 
> >> > 
> >> > Would you be suggesting that a separate, stream-based API makes sense 
> even within the stdlib? 
> >> > 
> >> > I'm not really sure what that separate API would look like, or do 
> differently than my proposal (I'm open to new ideas, though). 
> >> > 
> >> > Given that the "Go way" of handling streams is with 
> io.Reader/io.Writer (as opposed to events, for example), and the internal 
> implementation of `json/encoding` is already so close to that, I wonder if 
> the APIs would end up looking very much the same, anyway. 
> >> > 
> >> > Jonathan 
> >> > 
> >> > 
> >> > On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote: 
> >> >> 
> >> >> In other environments (e.g. Java), the streaming processors are 
> distinct from the instance oriented - usually for good reason as the APIs 
> are very different - the former is usually event based, and the latter 
> returns realized instances as a whole or an error. The streaming processors 
> can often skip ill-formed entities, and/or have them manipulated during 
> decoding. 
> >> >> 
> >> >> -Original Message- 
> >> >> From: Jonathan Hall 
> >> >> Sent: Aug 9, 2019 10:38 AM 
> >> >> To: golang-nuts 
> >> >> Subject: Re: [go-nuts] RFC for opt-in streaming support in 
> encoding/json package 
> >> >> 
> >> >> Thanks for the reply. My responses inline below. 
> >> >> 
> >> >> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wro

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

I think you're right that most people are frustrated by the encoder, but as 
I mentioned in another message just a bit ago, the same fundamental problem 
exists with decoder, and for certain workloads, I believe it should be 
solved.

Having said that, I think tackling the writer first definitely makes the 
most sense.

With the decoder, at least it's possible, although terribly cumbersome, to 
cobble together a solution with the tokenizer interface of json.Decoder. 
And truth be told, my proposal wouldn't really elminate the use of the 
tokenizer interface--but it would make it possible to use it on a burried 
type (i.e. within a UnmarshalJSONStream() method), to achieve the benefit 
of stream reading.



On Friday, August 9, 2019 at 10:17:41 PM UTC+2, burak serdar wrote:
>
> On Fri, Aug 9, 2019 at 2:10 PM Robert Engels  > wrote: 
> > 
> > I'm sorry, maybe I didn't understand your original concern. There is an 
> example of doing stream based processing in the json package (using 
> Decoder). 
> > 
> > How is this not sufficient? 
> > 
> > The only problem I see with it is that it doesn't allow error 
> correction/continuation, but in the modern world that seems rather rare (or 
> very difficult to do well). 
>
> I was thinking similarly and after reading those github issues, it 
> looks like the main problem is with Encoder, and not with Decoder. 
> Encoder's problem can be solved by providing an unbuffered output 
> option that directly writes to the io.Writer. 
>
> I like the idea of stream-friendly marshaler/unmarshaler interfaces. 
>
> > 
> > -Original Message- 
> > From: Jonathan Hall 
> > Sent: Aug 9, 2019 11:00 AM 
> > To: golang-nuts 
> > Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
> package 
> > 
> > An interesting observation. 
> > 
> > Although in a sense, we already have the decoding half of that low-level 
> streaming API exposed by way of the `json.Decoder` type. 
> > 
> > Would you be suggesting that a separate, stream-based API makes sense 
> even within the stdlib? 
> > 
> > I'm not really sure what that separate API would look like, or do 
> differently than my proposal (I'm open to new ideas, though). 
> > 
> > Given that the "Go way" of handling streams is with io.Reader/io.Writer 
> (as opposed to events, for example), and the internal implementation of 
> `json/encoding` is already so close to that, I wonder if the APIs would end 
> up looking very much the same, anyway. 
> > 
> > Jonathan 
> > 
> > 
> > On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote: 
> >> 
> >> In other environments (e.g. Java), the streaming processors are 
> distinct from the instance oriented - usually for good reason as the APIs 
> are very different - the former is usually event based, and the latter 
> returns realized instances as a whole or an error. The streaming processors 
> can often skip ill-formed entities, and/or have them manipulated during 
> decoding. 
> >> 
> >> -Original Message- 
> >> From: Jonathan Hall 
> >> Sent: Aug 9, 2019 10:38 AM 
> >> To: golang-nuts 
> >> Subject: Re: [go-nuts] RFC for opt-in streaming support in 
> encoding/json package 
> >> 
> >> Thanks for the reply. My responses inline below. 
> >> 
> >> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote: 
> >>> 
> >>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  
> wrote: 
> >>> > 
> >>> > Can you say more? Better in which way? 
> >>> 
> >>> Better in the way that it wouldn't change existing code. 
> >> 
> >> 
> >> That doesn't seem like a benefit, in its own right 
> >> 
> >> I understand the desire not to just change code for its own sake, or 
> add extra features nobody needs. But people have been asking for these 
> types of features for several years.  This doesn't seem like a frivolous 
> code change to me. 
> >> 
> >>> 
> >>> Also, I think 
> >>> the use cases for existing and proposed json encoders/decoders are 
> >>> different enough to justify a separate implementation. 
> >> 
> >> 
> >> I don't think I agree with this. 
> >> 
> >> The proposal deals with a subset of current use cases, but not, 
> strictly speaking, a _different set_ of use cases. And the number of 
> commentators on the issues linked above, I think lends weight to the idea 
> that the use cases this proposal addresses are not insignificant, or 
> fundamentally

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

Oh, thanks for pointing that out.

it is indeed very similar to my proposal. What do you think the chances of 
getting it resurrected and merged? Is more discussion still needed with 
respect to sync.Pool?

On Friday, August 9, 2019 at 6:15:31 PM UTC+2, Ian Davis wrote:
>
> You may also be interested in a CL I created last year to add an 
> unbuffered write mode to the encoder
>
> https://go-review.googlesource.com/c/go/+/135595
>
> I think I addressed all the review comments but it stalled behind a 
> tangential issue around the current version's use of sync.Pool 
> https://github.com/golang/go/issues/27735
>
> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8b8b8eb8-48bd-4a89-964a-52c8e7c71d39%40googlegroups.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

The problem is that when encoding, even with json.Encoder, the entire 
object is marshaled, into memory, before it is written to the io.Writer. My 
proposal allows writing the JSON output immediately, rather than waiting 
for the entire process to complete successfully first.

The same problem occurs in reverse--when reading a large JSON response, you 
cannot begin processing the result until the entire result is received.

To anchor these abstract concepts to real life, let me offer an example of 
each where this is quite painful:

When writing a CouchDB document, it may contain an arbitrary amount of 
data, possibly even including BASE64-encoded attachments. For some extreme 
cases, these documents may be multiple mb. Dozens or hundreds of kb is not 
at all unusual. A typical use case may have 10k of normal JSON, with an 
additional 200k of, say, an image.  The current JSON implementation buffers 
this entire payload, ensures there are no marshaling errors, then writes to 
the `io.Writer`.  My proposal would allow writing immediately, with no need 
to buffer 100s of kb of JSON.

In the case of CouchDB, the reverse may actually be more harmful (and I've 
already gone to some lengths to mitigate the worst of it, using 
json.Decoder's tokenizer API):

A typical query returns multiple documents (which, again, may be up to 
hundreds of kb each).  With the existing implementation, one must read the 
entire resultset from the network, before parsing the first document. My 
proposal would make it possible to begin reading the individual JSON 
documents (and indeed, even individual parts of said document), without 
waiting for the entire result to be buffered.



On Friday, August 9, 2019 at 10:10:23 PM UTC+2, Robert Engels wrote:
>
> I'm sorry, maybe I didn't understand your original concern. There is an 
> example of doing stream based processing in the json package (using 
> Decoder).
>
> How is this not sufficient?
>
> The only problem I see with it is that it doesn't allow error 
> correction/continuation, but in the modern world that seems rather rare (or 
> very difficult to do well).
>
> -Original Message- 
> From: Jonathan Hall 
> Sent: Aug 9, 2019 11:00 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
> package 
>
> An interesting observation.
>
> Although in a sense, we already have the decoding half of that low-level 
> streaming API exposed by way of the `json.Decoder` type.
>
> Would you be suggesting that a separate, stream-based API makes sense even 
> within the stdlib?
>
> I'm not really sure what that separate API would look like, or do 
> differently than my proposal (I'm open to new ideas, though).
>
> Given that the "Go way" of handling streams is with io.Reader/io.Writer 
> (as opposed to events, for example), and the internal implementation of 
> `json/encoding` is already so close to that, I wonder if the APIs would end 
> up looking very much the same, anyway.
>
> Jonathan
>
>
> On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote:
>>
>> In other environments (e.g. Java), the streaming processors are distinct 
>> from the instance oriented - usually for good reason as the APIs are very 
>> different - the former is usually event based, and the latter returns 
>> realized instances as a whole or an error. The streaming processors can 
>> often skip ill-formed entities, and/or have them manipulated during 
>> decoding.
>>
>> -Original Message- 
>> From: Jonathan Hall 
>> Sent: Aug 9, 2019 10:38 AM 
>> To: golang-nuts 
>> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
>> package 
>>
>> Thanks for the reply. My responses inline below.
>>
>> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>>>
>>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote: 
>>> > 
>>> > Can you say more? Better in which way? 
>>>
>>> Better in the way that it wouldn't change existing code.
>>
>>
>> That doesn't seem like a benefit, in its own right
>>
>> I understand the desire not to just change code for its own sake, or add 
>> extra features nobody needs. But people have been asking for these types of 
>> features for several years.  This doesn't seem like a frivolous code change 
>> to me.
>>  
>>
>>> Also, I think 
>>> the use cases for existing and proposed json encoders/decoders are 
>>> different enough to justify a separate implementation.
>>
>>
>> I don't think I agree with this.
>>
>> The proposal deals with a subset of current use cases, but not, strictly 
>> speaking,

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

An interesting observation.

Although in a sense, we already have the decoding half of that low-level 
streaming API exposed by way of the `json.Decoder` type.

Would you be suggesting that a separate, stream-based API makes sense even 
within the stdlib?

I'm not really sure what that separate API would look like, or do 
differently than my proposal (I'm open to new ideas, though).

Given that the "Go way" of handling streams is with io.Reader/io.Writer (as 
opposed to events, for example), and the internal implementation of 
`json/encoding` is already so close to that, I wonder if the APIs would end 
up looking very much the same, anyway.

Jonathan


On Friday, August 9, 2019 at 5:53:41 PM UTC+2, Robert Engels wrote:
>
> In other environments (e.g. Java), the streaming processors are distinct 
> from the instance oriented - usually for good reason as the APIs are very 
> different - the former is usually event based, and the latter returns 
> realized instances as a whole or an error. The streaming processors can 
> often skip ill-formed entities, and/or have them manipulated during 
> decoding.
>
> -Original Message- 
> From: Jonathan Hall 
> Sent: Aug 9, 2019 10:38 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] RFC for opt-in streaming support in encoding/json 
> package 
>
> Thanks for the reply. My responses inline below.
>
> On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>>
>> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  wrote: 
>> > 
>> > Can you say more? Better in which way? 
>>
>> Better in the way that it wouldn't change existing code.
>
>
> That doesn't seem like a benefit, in its own right
>
> I understand the desire not to just change code for its own sake, or add 
> extra features nobody needs. But people have been asking for these types of 
> features for several years.  This doesn't seem like a frivolous code change 
> to me.
>  
>
>> Also, I think 
>> the use cases for existing and proposed json encoders/decoders are 
>> different enough to justify a separate implementation.
>
>
> I don't think I agree with this.
>
> The proposal deals with a subset of current use cases, but not, strictly 
> speaking, a _different set_ of use cases. And the number of commentators on 
> the issues linked above, I think lends weight to the idea that the use 
> cases this proposal addresses are not insignificant, or fundamentally 
> "different".
>
> If I were to fork the standard `encoding/json` library, and add my 
> proposed functionality, the code would still be 95% the same. Standard 
> reasons for sharing code apply, as far as I can tell.
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/718e2b9e-39e2-44f2-9308-8c94e31afbff%40googlegroups.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

Thanks for the reply. My responses inline below.

On Friday, August 9, 2019 at 5:14:52 PM UTC+2, burak serdar wrote:
>
> On Fri, Aug 9, 2019 at 8:53 AM Jonathan Hall  > wrote: 
> > 
> > Can you say more? Better in which way? 
>
> Better in the way that it wouldn't change existing code.


That doesn't seem like a benefit, in its own right

I understand the desire not to just change code for its own sake, or add 
extra features nobody needs. But people have been asking for these types of 
features for several years.  This doesn't seem like a frivolous code change 
to me.
 

> Also, I think 
> the use cases for existing and proposed json encoders/decoders are 
> different enough to justify a separate implementation.


I don't think I agree with this.

The proposal deals with a subset of current use cases, but not, strictly 
speaking, a _different set_ of use cases. And the number of commentators on 
the issues linked above, I think lends weight to the idea that the use 
cases this proposal addresses are not insignificant, or fundamentally 
"different".

If I were to fork the standard `encoding/json` library, and add my proposed 
functionality, the code would still be 95% the same. Standard reasons for 
sharing code apply, as far as I can tell.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/df688733-a2e9-4bc8-aa7b-09267827007a%40googlegroups.com.

Re: [go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

Can you say more? Better in which way?


On Friday, August 9, 2019 at 4:46:19 PM UTC+2, burak serdar wrote:
>
>
> Instead of modifying the existing Encoder/Decoder, wouldn't it be 
> better to do this as a separate encoder/decoder? 
>
>
>
>
> > 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9b081989-0ffa-40a1-8d6b-f56833e7b749%40googlegroups.com.
>  
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cc2b65c1-4abc-4309-b0c8-b311456873ee%40googlegroups.com.

[go-nuts] RFC for opt-in streaming support in encoding/json package

[Jonathan Hall]

*I debated posting here, or straight to GitHub. If that's the better place, 
I can move the thread there. * I have long wanted proper streaming support 
in the `encoding/json` library. Lately I’ve been doing some digging to 
understand the current state of things, and I think I’ve come to grips with 
most of it.

A number of previous issues relate to this topic: 
https://github.com/golang/go/issues/7872, 
https://github.com/golang/go/issues/11046, 
https://github.com/golang/go/issues/12001, 
https://github.com/golang/go/issues/14140

I have read through each of these issues, and believe I have a fair 
understanding of the problems associated with streaming JSON input/output. 
If I'm overlooking something please enlighten me.

In a nutshell: The library implicitly guarantees that marshaling will never 
write an incomplete JSON object due to an error, and that during 
unmarshaling, it will never pass an incomplete JSON message to 
`UnmarshalJSON`.

Work toward this was done about 3 years ago, on this CL: 
https://go-review.googlesource.com/c/go/+/13818/

Workt was eventually abandoned, apparently when the author was unsure how 
to make the new behavior opt-in. I believe this proposal will solve that 
issue.

*The problem to be solved*

Dealing with large JSON structures is inefficient, due to the internal 
buffering done by `encoding/json`. `json.NewEncoder` and `json.NewDecoder` 
appear to offer streaming benefits, but this is mostly an idiomatic 
advantage, not a performance one, as internal buffering still takes place. 
Particular aspects of the broader problem are already addressed on the 
above mentioned links, and benefits of streaming should be easy to imagine, 
so I won't bore people with details unless someone asks. 

*A naïve solution*

I believe a simple solution (simple from the perspective of a consumer of 
the library--the internal changes are not so simple) would be to add two 
interfaces:

type StreamMarshaler interface {

MarshalJSONStream(io.Writer) error

}

type StreamUnmarshaler interface {

UnmarshalJSONStream(io.Reader) error

}

During (un)marshaling, where `encoding/json` looks for `json.Marshaler` and 
`json.Unmarshaler` respectively, it will now look for (and possibly prefer) 
the new interfaces instead. Wrapping either the old or new interfaces to 
work as the other is a trivial matter.

With this change, and the requisite internal changes, it would be possible 
to begin streaming large JSON data to a server immediately, from within a 
`MarshalJSONStream()` implementation, for instance.

The drawback is that it violates the above mentioned promise of complete 
reads and writes, even with errors.

*Opt-in*

To accommodate this requirement, I believe it would be possible to expose 
the streaming functionality _only_ with the `json.Encoder` and 
`json.Decoder` implementations, and only when `EnablePartial*` (name TBD) 
is enabled.  So further, the following two functions would be added to the 
public API:

func (*Encoder) EnablePartialWrites(on bool)

func (*Decoder) EnablePartialReads(on bool)

The default behavior, even when a type implements one of the new `Stream*` 
interfaces, will be to operate on an entire JSON object at once. That is to 
say, the Encoder will internally buffer `MarshalJSONStream`'s output, and 
process any error before continuing, and a decoder will read an entire JSON 
object into a buffer, then pass it to `UnmarshalJSONStream` only if there 
are no errors.

However, when `EnablePartial*` is enabled, the library will bypass this 
internal buffering, allowing for immediate streaming to/from the 
source/destination.

Enabling streaming with the `EnablePartial*` toggle could be enough to 
already experience a benefit for many users, even without the use of the 
additional interfaces above.

Toggling `EnablePartial*` on will, of course, enable streaming for all 
types, not just those which implement the new interface above, so this 
could be considered a separate part of the proposal. In my opinion, this 
alone would be worth implementing, even if the new interface types above 
are done later or never.

*Internals*

CL 13818 can serve as very informative for this part of the discussion. 
I've also done some digging in the `encoding/json` package (as of 1.12) 
recently, for more current context. A large number of internal changes will 
be necessary to allow for this. I started playing around with a few 
internals, and I believe this is doable, but will mean a lot of code churn, 
so will need to be done carefully, in small steps with good code review.

As an exercise, I have successfully rewritten`indent()` to work with 
streams, rather than on byte slices, and began doing the same with 
`compact()`. The `encodeState` type would need to work with a standard 
`io.Writer` rather than specifically a `bytes.Buffer`. This seems to be a 
bigger change, but not technically difficult. I know there are other 
changes needed--I 

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

[Jonathan Amsterdam]

On Friday, September 14, 2018 at 8:06:31 PM UTC-4, alanfo wrote:
>
> Thanks for your comments, Jonathan.
>
> I did in fact deal with all the cases you mention in my 'fuller' proposal:
>
> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
>
> where I'd used a device to restrict the built-ins to just one following 
> criticism by Ian that an earlier proposal I'd made had too many of them (it 
> had 14). 
>
> However, I decided instead to restrict the built-ins to a reasonable 
> number (6) in the simplified proposal which meant that many of them had to 
> go.
>

Your 'fuller' proposal says that you can "or" the builtins together. But if 
you have that, you can get rid of many of them. For instance, "complex" is 
just "complex64 or complex128".

>
> The example you mentioned was taken from the draft design paper and didn't 
> compile for int8 there either. 
>

Sorry, I shouldn't have used the word "compile" because it's ambiguous. 
Neither your Add1K nor the draft design's can be instantiated for int8. 
However, the draft design Add1K is valid with respect to its contract. 
Yours isn't, because the contract admits int8 but the function doesn't.

-- 
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] A simplified generics constraint system.

[Jonathan Amsterdam]

I'm sympathetic to the general idea, but I don't think this quite does it. 
In addition to introducing a bunch of new names, it's not expressive enough:

- You can't express "string or []byte", as you note. There are many 
algorithms where this would be useful. See the strings and bytes packages 
for a start.

- You can't support types that have bool and string as underlying types. 
People often define their own string type, usually just for clarity. You 
say they can just convert to string, but they can't if they have a 
[]MyString or the like. It's also confusingly inconsistent to support 
underlying types for numbers but not bool or string.

- Your convert example excludes complex types. You have no way to express 
"any numeric type," which is what that example needs.

- You can't get finer-grained than Integer. That excludes some code. For 
instance, your Add1K example doesn't work, because it won't compile if T = 
int8. It's not clear how important this is in practice.

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

[go-nuts] Re: Go 2 error-handling counter-proposal: returnfrom

[Jonathan Amsterdam]

What's the meaning of this code?

   func main() {
   f := g()
   f()
}

   func g() func() {
   Top:
   return func() { returnfrom Top,   nil}
   }

On Thursday, September 13, 2018 at 3:29:03 PM UTC-4, Scott Pakin wrote:
>
> I recently added to the Go 2 Error Handling Feedback 
>  page my 
> thoughts on how to improve upon the draft design for error handling 
> 
> :
>
> Go 2 error handling based on non-local returns 
> 
>
>
> You can read the details by clicking on that link, but the idea is to 
> introduce a single new keyword, returnfrom, that a function can use to 
> return from a lexically enclosing scope.  Thus, one can define an error 
> handler—as an ordinary function, not a handle.  One can check any status 
> type—unlike check, which is limited to error.  And one can stack error 
> handlers, but this is explicit, not implicit as in handle.
>
> Personally, I find returnfrom to be a better solution than check/handle 
> while still retaining the key benefits of that approach.  See what you 
> think.
>
> — Scott
>
>

-- 
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] Scrapping contracts (was: "Generics as bultin typeclasses")

[Jonathan Amsterdam]

Not to be snide, but we are looking for examples, not kinds of examples. Do 
you know of actual code where this would benefit?

For example, could field accessors improve the standard image and 
image/color packages? 

On Wednesday, September 12, 2018 at 9:15:24 AM UTC-4, Mandolyte wrote:
>
> On field accessors... 
>
> - Algorithms for X,Y points requiring them to be members of a struct type.
>
> - Algorithms to manipulate colors, requiring R,G, and B to be members.
>
> In an image processing library with its own rich set of struct types, such 
> accessors would prove productive.
>
> Are these the kind of examples you meant?
>
>

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

On Tuesday, September 11, 2018 at 9:24:56 AM UTC-4, Larry Clapp wrote:
>
> This question frankly struck me odd, given the context.  To paraphrase: 
> "Do I have examples of where accessing a field in a generic struct type 
> might be useful?"  I kind of assumed that, hip-deep as we are in a 
> discussion of generic functions, that such a thing might be understood?  I 
> mean, accessing struct fields in functions is ... useful?  Would not 
> accessing struct fields in generic functions be ... similarly useful?  I am 
> honestly befuddled.
>

Sorry for the confusion. I was asking for actual real-world examples where 
this would be useful, in any of the code you write or maintain. 

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

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

[Jonathan Amsterdam]

>
> * I think constraining type-parameters to channel/slice/map types might 
> not be needed at all. Instead of, say "func Foo(type T channelOfBar) (ch 
> T)", ISTM that we can use "func Foo(ch chan Bar)". Since any channel-type 
> with element type Bar can be assigned to `chan Bar`, this would already 
> allow most of the useful patterns. As-is there is a slight reduction in 
> power over the contracts design, because `contract channelOfBar(v T) { ch 
> <- Bar{} }` also allows element types that Bar is assignable to. 
> `assignableFrom(Bar)` would enable pseudo-interfaces to do that too. But 
> IMO it would be helpful to see cases where that's needed (AFAICT none of 
> the ones mentioned in the design doc or problem overview do).
>

Some of the examples could be generalized. For instance, Copy(dest []T1, 
src []T2) where T2 is assignable to T1.

How about merging channels c1 and c2 into c3? You could write this as

   func Merge(type T)(c1, c2, c3 chan T)

but  the more general version is 

   func Merge(type T1, T2, T3)(c1 chan T1, c2 chan T2, c3 chan T3)

where you can assign T1 and T2 to T3.

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

A lot of those just pick out a subset of built-in types (or a type whose 
underlying type is a built-in). boolean is an obvious example, but arith is 
just all the numeric types.

We already have names for those: int, bool, etc. We just need to combine 
them with "or". E.g. bool is "underlying(bool)", complex is 
"underlying(complex64) | underlying(complex128)".

I don't think any of the index or channel constraints are necessary. You 
can just put those in the function definition, e.g.

   func collect(type T)(c chan T) []T


On Monday, September 10, 2018 at 7:45:04 PM UTC-4, Axel Wagner wrote:
>
> The unambiguous cases aren't ambiguous of course. It's the ambiguous cases 
> I'm concerned about :) My post and this thread contain a bunch of those. 
> They are mostly growing out of builtin functions and things like `range` 
> statements and index-expressions.
>
> You can translate all of my "pseudo-interfaces" into a clear and short 
> contract
>
> contract comparable (v T) { v == v } // also allows !=
> contract ordered (v T) { v < v } // also allows <=, >, >=
> contract boolean (v T) { v || v } // also allows &&, !
> contract bitwise (v T) { v & v } // also allows |, ^, <<, >>
> contract arith (v T) { v * v } // also allows +, -, /
> // well, this one's a bit harder…
> contract concat (v T) { v + v; v == "" } // also allows range, index[int], 
> copy
> contract complex (v T) { real(v) } // also allows imag(v)
> contract nilable (v T) { v == nil } // also allows != nil
>
> There is some discussion about maps, slices and channels to be had - but I 
> think the vast majority of interesting cases can be covered by taking e.g. 
> a `chan T`. A defined type with underlying type `chan T` is assignable to 
> that, so it would appear a perfectly fine way to express this contract
> contract Chan (ch C, el T) { var x T = <-ch; ch <- x }
> (and correspondingly for send/recv-only channels).
>
> You can't express field-accessors, which is an actual, inarguable 
> reduction in power that I'm perfectly fine with (similarly to how we're 
> fine with interfaces not being able to express that).
>
> Which IMO brings up the question: If we can express the vast majority (or 
> even all) of the needed contracts as combinations of this handful of 
> base-cases, why would we need to allow the full power of Go syntax, which 
> enables to write all the less than obvious ones too?
>
> (to re-emphasize: All of this isn't polished. I did sanity-check against 
> the examples in the contract design doc, but I have not put enough thought 
> into it that there might not be a couple nooks and crannies I haven't 
> thought of, as you've proven before :) )
>
> On Tue, Sep 11, 2018 at 1:21 AM Jonathan Amsterdam  > wrote:
>
>>
>>
>> On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote:
>>>
>>> On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam  
>>> wrote:
>>>
>>>> FWIW, I think Ian's criticism of not wanting a list of new identifiers 
>>>>> to express operator constraints is fair. It is a genuine roadblock to c) 
>>>>> and if we're dead set of setting that as a baseline requirement, I agree 
>>>>> that a declarative/interface-based approach won't work. 
>>>>>
>>>>
>>>> I don't understand. Why are names so important? Why couldn't you use "T 
>>>> == T" to mean "T is comparable"? Or "To(From)" to mean "From is 
>>>> convertible 
>>>> to To"?
>>>>
>>>
>>> It's not the name that is important, it's the declarative nature. I and 
>>> other people have already gone into detail with the problems we are having 
>>> with using imperative constructs to define constraints (mainly that they 
>>> are ambiguous and that it's hard both to enumerate the sets allowed by a 
>>> contract and to define a suitable contract for an intended set of 
>>> constraints).
>>>
>>
>> I completely agree with you there (although I find the 
>> declarative/imperative terminology confusing). I think that except for 
>> interface-like constraints, we should be constraining by broad properties 
>> of types like comparable, ordered and numeric, rather than specific 
>> operations.
>>
>>>  
>>>
>> I don't care if the declarative instruction is called "flooglehorn" or 
>>> "comparable". But I do care that it's an an actual declaration, mapping 1:1 
>>> in a clear way to intent. Not an ambiguous statement from Go's current 
>>> 

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

[Jonathan Amsterdam]

Do you have actual examples of how that would be useful to you?

On Monday, September 10, 2018 at 9:45:12 PM UTC-4, Larry Clapp wrote:
>
> The conversation here is deep, and I haven't followed all of it.  I 
> *think* y'all are discussing some different contract system than the 
> actual draft proposal?
>
> If that's the case:
>
> You can't express field-accessors, which is an actual, inarguable 
>> reduction in power that I'm perfectly fine with
>
>
> How would you instantiate a generic function that wanted to access field F 
> of a generic type T?
>
> if you can't do that, well, I'm not fine with that.
>
> But I may have misunderstood.
>
> — L
>
> On Monday, September 10, 2018 at 7:45:04 PM UTC-4, Axel Wagner wrote:
>>
>> The unambiguous cases aren't ambiguous of course. It's the ambiguous 
>> cases I'm concerned about :) My post and this thread contain a bunch of 
>> those. They are mostly growing out of builtin functions and things like 
>> `range` statements and index-expressions.
>>
>> You can translate all of my "pseudo-interfaces" into a clear and short 
>> contract
>>
>> contract comparable (v T) { v == v } // also allows !=
>> contract ordered (v T) { v < v } // also allows <=, >, >=
>> contract boolean (v T) { v || v } // also allows &&, !
>> contract bitwise (v T) { v & v } // also allows |, ^, <<, >>
>> contract arith (v T) { v * v } // also allows +, -, /
>> // well, this one's a bit harder…
>> contract concat (v T) { v + v; v == "" } // also allows range, 
>> index[int], copy
>> contract complex (v T) { real(v) } // also allows imag(v)
>> contract nilable (v T) { v == nil } // also allows != nil
>>
>> There is some discussion about maps, slices and channels to be had - but 
>> I think the vast majority of interesting cases can be covered by taking 
>> e.g. a `chan T`. A defined type with underlying type `chan T` is assignable 
>> to that, so it would appear a perfectly fine way to express this contract
>> contract Chan (ch C, el T) { var x T = <-ch; ch <- x }
>> (and correspondingly for send/recv-only channels).
>>
>> You can't express field-accessors, which is an actual, inarguable 
>> reduction in power that I'm perfectly fine with (similarly to how we're 
>> fine with interfaces not being able to express that).
>>
>> Which IMO brings up the question: If we can express the vast majority (or 
>> even all) of the needed contracts as combinations of this handful of 
>> base-cases, why would we need to allow the full power of Go syntax, which 
>> enables to write all the less than obvious ones too?
>>
>> (to re-emphasize: All of this isn't polished. I did sanity-check against 
>> the examples in the contract design doc, but I have not put enough thought 
>> into it that there might not be a couple nooks and crannies I haven't 
>> thought of, as you've proven before :) )
>>
>> On Tue, Sep 11, 2018 at 1:21 AM Jonathan Amsterdam  
>> wrote:
>>
>>>
>>>
>>> On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote:
>>>>
>>>> On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam  
>>>> wrote:
>>>>
>>>>> FWIW, I think Ian's criticism of not wanting a list of new identifiers 
>>>>>> to express operator constraints is fair. It is a genuine roadblock to c) 
>>>>>> and if we're dead set of setting that as a baseline requirement, I agree 
>>>>>> that a declarative/interface-based approach won't work. 
>>>>>>
>>>>>
>>>>> I don't understand. Why are names so important? Why couldn't you use 
>>>>> "T == T" to mean "T is comparable"? Or "To(From)" to mean "From is 
>>>>> convertible to To"?
>>>>>
>>>>
>>>> It's not the name that is important, it's the declarative nature. I and 
>>>> other people have already gone into detail with the problems we are having 
>>>> with using imperative constructs to define constraints (mainly that they 
>>>> are ambiguous and that it's hard both to enumerate the sets allowed by a 
>>>> contract and to define a suitable contract for an intended set of 
>>>> constraints).
>>>>
>>>
>>> I completely agree with you there (although I find the 
>>> declarative/imperative terminology confusing). I think that except for 
>>> interface-like constraints, we should be constraining by broad

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

[Jonathan Amsterdam]

On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote:
>
> On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam  > wrote:
>
>> FWIW, I think Ian's criticism of not wanting a list of new identifiers to 
>>> express operator constraints is fair. It is a genuine roadblock to c) and 
>>> if we're dead set of setting that as a baseline requirement, I agree that a 
>>> declarative/interface-based approach won't work. 
>>>
>>
>> I don't understand. Why are names so important? Why couldn't you use "T 
>> == T" to mean "T is comparable"? Or "To(From)" to mean "From is convertible 
>> to To"?
>>
>
> It's not the name that is important, it's the declarative nature. I and 
> other people have already gone into detail with the problems we are having 
> with using imperative constructs to define constraints (mainly that they 
> are ambiguous and that it's hard both to enumerate the sets allowed by a 
> contract and to define a suitable contract for an intended set of 
> constraints).
>

I completely agree with you there (although I find the 
declarative/imperative terminology confusing). I think that except for 
interface-like constraints, we should be constraining by broad properties 
of types like comparable, ordered and numeric, rather than specific 
operations.

>  
>
I don't care if the declarative instruction is called "flooglehorn" or 
> "comparable". But I do care that it's an an actual declaration, mapping 1:1 
> in a clear way to intent. Not an ambiguous statement from Go's current 
> Grammar.
>

It wouldn't be ambiguous. The spec would say "in type constraints, `T == T` 
means that T is comparable". I think people would learn to understand that, 
just as they understand that for a type T, `*T` means "pointer to T," not 
"dereference T".


 

>  
>

> Personally, I don't think that should be a requirement. Personally I think 
>>> it's worth adding extra identifiers, if we get declarative constraint-specs 
>>> for that - but that's just my opinion and everyone has one of those.
>>>
>>> But the issues you are bringing up are IMO not "fundamental'. a) to c) 
>>> from above aren't really touched by your criticism, AIUI. To me, they seem 
>>> like issues of syntax and how to phrase the spec.
>>>
>>> But if generics are to have operator constraints like T == T, then 
>>>> something in the language has to change. Either not all interfaces are 
>>>> types, or some interfaces have methods that can't be called, or Go 
>>>> operators can have operands of different types. These changes are not 
>>>> minor 
>>>> tweaks: they alter fundamental aspects of the language.
>>>>
>>>> Contracts, on the other hand, are purely additive. They only come into 
>>>> play when writing generic code. If I'm not mistaken, the draft design 
>>>> doesn't change or even add anything to non-generic Go. There is something 
>>>> attractive about that orthogonality.
>>>>
>>>
>>> I agree. I think that's fair. I don't think for that they need to be 
>>> imperative specifications though.
>>>
>>>  (or, allow embedding interfaces into contract-declarations, remove the 
>>>>> "type-checking function body" idea and instead define a set of 
>>>>> base-contracts you can use for operators) and you'd end up with pretty 
>>>>> much 
>>>>> my design.
>>>>>
>>>>
>>>> That doesn't sound like your original design at all.
>>>>
>>>
>>> You need to squint harder :) From the rest of your mail, ISTM that we 
>>> are putting emphasis on different aspects of my description and the 
>>> contracts design. What I was trying to say is that IMO the things about my 
>>> design I like and the things about the contract design you like can 
>>> probably be reconciled.
>>>
>>> The first seems problematic, because for multi-parameter contracts you 
>>>> wouldn't know which type the parameter referred to. 
>>>>
>>>
>>> FWIW (we are now getting lost in ifs-and-buts and it's no longer clear 
>>> what the specific ideas are we are talking about), in my original design as 
>>> well as that ad-how handwaving you're quoting, constraints always apply to 
>>> a single type and you'd use parametric interfaces (or… interfaces+) to 
>>> express simultaneous restrictions.
>>>
>>> But FTR, I did not intend to start an actu

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

[Jonathan Amsterdam]

I'm wrong about `==` here, because it's defined for interface values. 
`comparable` could be an interface.

But it won't work for other operators like `<` or `+`.

On Sunday, September 9, 2018 at 2:49:26 PM UTC-4, Jonathan Amsterdam wrote:
>
> FWIW, in my pseudo-interface description 
>> <https://blog.merovius.de/2018/09/05/scrapping_contracts.html> ...
>>
>
> You mention that comparable is a pseudo-interface, which means the type 
> supports the == and != operators. You say that comparable and the other 
> pseudo-interfaces are types.
>
> So I should be able to write a function like
>
>   func f(x, y comparable) bool { return x == y }
>
> And of course I can call it like so:
>
>var x int
>var y float32
>f(x, y)
>
> The problem is that this program seems to type-check, but it is invalid. 
> The == operator is specified to work on operands of the same type, and it 
> is being used on operands of different types.
>
> This is the fundamental problem with using interfaces for operators.
>
> And since we need some operators for generics (at least == and <), it is 
> also one of the fundamental problems with unifying interfaces and contracts.
>

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

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

[Jonathan Amsterdam]

Sorry, I'm wrong about `eq`. It could be an interface, because `==` is 
treated specially for interface types.

But you couldn't have an interface for any other operator, like `<` or `+`.

On Monday, September 10, 2018 at 9:55:04 AM UTC-4, Jonathan Amsterdam wrote:
>
> From the blog post:
>
> For example there could be an eq interface that’s equivalent to a contract 
>> with an x == x. 
>
>
> Actually, there can't. If eq were an interface, then 
>
>func f(x, y eq) bool { return x == y }
>
> would be legal. And so would the call
>
>  var a int
>  var b float64
>  f(a, b)
>
>  since both int and float64 support ==. 
>
> The problem is that the spec says that the operands of == have to be the 
> same type, so this code is invalid. 
> It's hard to see how to fix the problem without changing something 
> fundamental about the language.
>
> On Sunday, September 2, 2018 at 4:08:48 AM UTC-4, Charlton Trezevant wrote:
>>
>> Link: [Getting specific about generics, by Emily Maier](
>> https://emilymaier.net/words/getting-specific-about-generics/)
>>
>> The interface-based alternative to contracts seems like such a natural 
>> fit- It’s simple, straightforward, and pragmatic. I value those aspects of 
>> Go’s philosophy and consider them to be features of the language, so it’s 
>> encouraging to see a solution that suits them so well. The author also does 
>> a great job of contextualizing the use cases and debate around generics, 
>> which I found incredibly helpful.
>>
>> Any thoughts?
>>
>

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

low that and that's the whole point 
>>> I'm making. So this doesn't seem like a particularly nice way to have a 
>>> discussion.
>>>
>>> But yes, if it makes you happier, we can call them "contracts", allow to 
>>> embed them into interfaces and remove contract declarations from the design 
>>> (or, allow embedding interfaces into contract-declarations, remove the 
>>> "type-checking function body" idea and instead define a set of 
>>> base-contracts you can use for operators) and you'd end up with pretty much 
>>> my design.
>>>
>>> On Sun, Sep 9, 2018 at 11:17 PM Jonathan Amsterdam  
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote:
>>>>>
>>>>> On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam  
>>>>> wrote:
>>>>>
>>>>>> The problem is that this program seems to type-check, but it is 
>>>>>> invalid. The == operator is specified to work on operands of the same 
>>>>>> type, 
>>>>>> and it is being used on operands of different types.
>>>>>>
>>>>>
>>>>> Good point. I have to think about it. An ad-hoc solution, FWIW, would 
>>>>> be to only take into account (or allow) pseudo-interfaces for 
>>>>> type-constraints.
>>>>>
>>>>
>>>> The draft design has a name for those: contracts.
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

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

[Jonathan Amsterdam]

>
>
> The problem is that the spec says that the operands of == have to be the 
> same type
>

Correction: one operand must be assignable to the type of the other. 

The example still stands: you can't compare an int and a float64. 

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

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

[Jonathan Amsterdam]

>From the blog post:

For example there could be an eq interface that’s equivalent to a contract 
> with an x == x. 


Actually, there can't. If eq were an interface, then 

   func f(x, y eq) bool { return x == y }

would be legal. And so would the call

 var a int
 var b float64
 f(a, b)

 since both int and float64 support ==. 

The problem is that the spec says that the operands of == have to be the 
same type, so this code is invalid. 
It's hard to see how to fix the problem without changing something 
fundamental about the language.

On Sunday, September 2, 2018 at 4:08:48 AM UTC-4, Charlton Trezevant wrote:
>
> Link: [Getting specific about generics, by Emily Maier](
> https://emilymaier.net/words/getting-specific-about-generics/)
>
> The interface-based alternative to contracts seems like such a natural 
> fit- It’s simple, straightforward, and pragmatic. I value those aspects of 
> Go’s philosophy and consider them to be features of the language, so it’s 
> encouraging to see a solution that suits them so well. The author also does 
> a great job of contextualizing the use cases and debate around generics, 
> which I found incredibly helpful.
>
> Any thoughts?
>

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

On Sunday, September 9, 2018 at 3:52:24 AM UTC-4, Ian Lance Taylor wrote:
>
> On Sat, Sep 8, 2018 at 7:53 PM, Jonathan Amsterdam 
> > wrote: 
> >>  When is it important to not just express what operations are 
> >> required for a type, but also to try to rule out some types?  

> 
> > 
> > I think the short answer is: numeric code. That's when one thinks about 
> > which types make sense for an algorithm, not just which operations. 
> > 
> > I'm not exactly sure why. It could be because Go doesn't support 
> operator 
> > overloading. In C++ with concepts, maybe the concept for writing some 
> > generic math function wants operator+ and operator/, and no one cares 
> that 
> > that may result in nonsense for some implementations of those operators. 
> > 
> >  In Go 1, we write numeric code with specific types: float64 and not 
> int64, 
> > for instance. Go  insists on conversions between numeric types to keep 
> us 
> > out of trouble: you can't call func Average(a, b float64) on ints 
> without 
> > explicitly converting them. It seems natural to want to keep that 
> precision 
> > and safety, but generalize it. 
> > 
> > In Go 1, if we wanted to write a numeric algorithm that worked on, say, 
> two 
> > slices of floating-point numbers, we'd give it the signature func(x, y 
> > []float64). If later we wanted to support float32, we'd have to copy the 
> > code, or make the caller do an expensive conversion. The same problem 
> would 
> > happen if the caller defined their own floating-point type (e.g. type 
> > MyFloat float64). 
> > 
> > I think I should be able to say, simply and clearly, that the slice 
> element 
> > can be any type whose underlying type is float32 or float64. 
> Furthermore, I 
> > don't want to specify the exact operations my implementation currently 
> uses. 
> > I may want to change the code to use "-" instead of "+" later, for 
> reasons 
> > of clarity or numerical stability. I shouldn't have to update the 
> contract 
> > for that. 
> > 
> > contract(t T) { t = 0.0 } might seem to restrict to the types I want, 
> but it 
> > doesn't; you can assign 0.0 to an integer type. 
> > 
> > contract(t T) { t = 0.5 } is wrong too. It includes complex types. 
> > 
> > contract(t T) { float64(t) } also works for ints, so no good. 
> > 
> > I believe the answer is 
> > 
> >contract(t T) { t = 0.5; float64(t) } 
> > 
> > but I'm not positive about that. Certainly, very few people who read 
> that 
> > will immediately understand that T is a type whose underlying type is a 
> > float. 
> > 
> > (And I haven't done the second part, where I add all the valid operators 
> for 
> > floats.) 
> > 
> > Earlier you wrote 
> > 
> >> [T]o me it always seems quite clear which type arguments a contract 
> allows 
> > and excludes.  It's exactly the set of types that type check 
> > successfully.  It's true that sometimes this can be a surprising type, 
> > but to me that seems just like the fact that it can be surprising 
> > which types implement an interface. 
> > 
> > I think this example, and the other ones given in this thread, 
> demonstrate 
> > that this is not "just like" the surprise of which types implement an 
> > interface. It's more like solving a puzzle, as someone (Axel?) has said. 
>
> It is like solving a puzzle because you are trying to figure out how 
> to exclude some types.  Why are you doing that?  Why not just describe 
> the types you accept, and not worry about other types?  Just as we do 
> for interface types? 
>

I feel I'm just using types as I always do, to describe (approximately) the 
valid 
values for something. I don't use float64 for a counter, I use int. I 
declare the name
field of a Person struct as string, not interface{}, even if I'm only going 
to print it and
compare it for equality.


> I don't yet find your Average example to be convincing.  Clearly if 
> Average is going to take values of type T and return a value of type 
> T, then if called on integers it is going to be a rounded value.  That 
> is inherent in the description.  


Agreed, Average is a poor example. Take something where the answer will 
always
be in floating-point, like standard deviation:

   func Stdev(type T)(xs []T) float64

I might naively write this as

   contract c(t T) { t + t; t - t; t/t; float64(t) }

   func Stdev(type T c)(xs []T) float64 {
mean := Average(xs)// generalizing my Average in the obvious way
s := 0.0
for _, x := range xs {
 d :=

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

[Jonathan Amsterdam]

You're right, I apologize. It not only wasn't nice, it also was an 
ineffective way to make my point. So let me try to make that point as 
clearly as I can.

You and many others have tried to replace contracts with interfaces. But if 
generics are to have operator constraints like T == T, then something in 
the language has to change. Either not all interfaces are types, or some 
interfaces have methods that can't be called, or Go operators can have 
operands of different types. These changes are not minor tweaks: they alter 
fundamental aspects of the language.

Contracts, on the other hand, are purely additive. They only come into play 
when writing generic code. If I'm not mistaken, the draft design doesn't 
change or even add anything to non-generic Go. There is something 
attractive about that orthogonality. 

Maybe there is a way to use interfaces in place of contracts, and I hope 
people keep trying, because the attraction is obvious. But in the all the 
suggestions I've seen so far, the cure is worse than the disease.

 (or, allow embedding interfaces into contract-declarations, remove the 
> "type-checking function body" idea and instead define a set of 
> base-contracts you can use for operators) and you'd end up with pretty much 
> my design.
>

That doesn't sound like your original design at all. Your original design 
tries to replace contracts with interfaces. In this suggestion, contracts 
are there, but (1) you can write an interface directly in the contract 
body, and (2) the body is much more restricted.

The first seems problematic, because for multi-parameter contracts you 
wouldn't know which type the parameter referred to.

The second seems reasonable to me. Now we can talk about issues like 
whether this adds too many names to the language, or whether you've 
described all the important constraints (I think conversion and 
assignability are important, for instance).
 

On Sunday, September 9, 2018 at 5:21:28 PM UTC-4, Axel Wagner wrote:
>
> I don't think saying that is is productive. contracts are more than just 
> "identifiers used as constraints", they are also a syntactic construct to 
> specify those. I specifically don't allow that and that's the whole point 
> I'm making. So this doesn't seem like a particularly nice way to have a 
> discussion.
>
> But yes, if it makes you happier, we can call them "contracts", allow to 
> embed them into interfaces and remove contract declarations from the design 
> (or, allow embedding interfaces into contract-declarations, remove the 
> "type-checking function body" idea and instead define a set of 
> base-contracts you can use for operators) and you'd end up with pretty much 
> my design.
>
> On Sun, Sep 9, 2018 at 11:17 PM Jonathan Amsterdam  > wrote:
>
>>
>>
>> On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote:
>>>
>>> On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam  
>>> wrote:
>>>
>>>> The problem is that this program seems to type-check, but it is 
>>>> invalid. The == operator is specified to work on operands of the same 
>>>> type, 
>>>> and it is being used on operands of different types.
>>>>
>>>
>>> Good point. I have to think about it. An ad-hoc solution, FWIW, would be 
>>> to only take into account (or allow) pseudo-interfaces for type-constraints.
>>>
>>
>> The draft design has a name for those: contracts.
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote:
>
> On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam  > wrote:
>
>> The problem is that this program seems to type-check, but it is invalid. 
>> The == operator is specified to work on operands of the same type, and it 
>> is being used on operands of different types.
>>
>
> Good point. I have to think about it. An ad-hoc solution, FWIW, would be 
> to only take into account (or allow) pseudo-interfaces for type-constraints.
>

The draft design has a name for those: contracts.

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

>
>
> func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to 
> Node) []Edge
>

I don't think this syntax is valid according to the draft design, or your 
blog post.  Node and Edge are used before they are declared. Maybe 

func ShortestPath(type Node, Edge, G Graph(Node, Edge)) (g G, from, to 
Node) []Edge

except according to your description, all three type parameters would have 
Graph(Node, Edge) as constraints, which doesn't make sense either.


> On Sun, Sep 9, 2018 at 8:21 PM Jonathan Amsterdam  > wrote:
>
>>
>>> FWIW, in my pseudo-interface description 
>>> <https://blog.merovius.de/2018/09/05/scrapping_contracts.html>, 
>>>
>>
>>  Unrelated to this particular issue, but since you link to your blog 
>> post, I just want to mention that in your graph example,
>>
>>   func ShortestPath(type Node, Edge) (g Graph(Node, Edge), from, to 
>> Node) []Edge 
>>
>>  will have dynamic dispatches in the body (since g is an ordinary 
>> interface value). The one in the draft design is completely static.
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

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 
> methods, e.g. operator + is 
>
> pseudo generic interface - not really required
>
> type PlusOperator interface {
>Plus(A) A
> }
>

This generic interface does not capture the + operator. The spec says that 
the the operands and result of + are all the same type. Your interface is 
satisfied by any type B with a method Plus(A) A. Types A and B do not have 
to be the same.



> type MyStruct struct {
> }
> func (MyStruct) Plus(other MyStruct) MyStruct {
>…
> }
>

but also

type MyOtherStruct struct{}
func (MyOtherStruct) Plus(other MyStruct) MyStruct {
}

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

>
> FWIW, in my pseudo-interface description 
>  ...
>

You mention that comparable is a pseudo-interface, which means the type 
supports the == and != operators. You say that comparable and the other 
pseudo-interfaces are types.

So I should be able to write a function like

  func f(x, y comparable) bool { return x == y }

And of course I can call it like so:

   var x int
   var y float32
   f(x, y)

The problem is that this program seems to type-check, but it is invalid. 
The == operator is specified to work on operands of the same type, and it 
is being used on operands of different types.

This is the fundamental problem with using interfaces for operators.

And since we need some operators for generics (at least == and <), it is 
also one of the fundamental problems with unifying interfaces and contracts.

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

>
>
> FWIW, in my pseudo-interface description 
> , 
>

 Unrelated to this particular issue, but since you link to your blog post, 
I just want to mention that in your graph example,

  func ShortestPath(type Node, Edge) (g Graph(Node, Edge), from, to Node) 
[]Edge 

 will have dynamic dispatches in the body (since g is an ordinary interface 
value). The one in the draft design is completely static.

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

I don't think Go will add operator overloading, even if it simplifies 
generics. Go has a core principle that doesn't get written down very much: 
syntax is hard-coded. If you see a piece of syntax in Go, it will never 
execute user code. (The obvious exception, of course, is a function call.) 
This principle makes Go extremely readable, and relatively easy to debug.

Even if Go had operator overloading, there's more to do. You talk about 
"slightly extended interfaces," but what are those? Your example

  type comparer(type T) interface {
  Less(other T)
  }

interpreted according to the current design, only describes some type U 
that has a method with signature Less(T). It doesn't say U and T are 
identical. You need to be more clear about what changes to interfaces are 
necessary.

Lastly, there's the problem of contracts with multiple type parameters, 
like the Graph example in the design draft. Operator overloading doesn't 
help with that.
 
On Saturday, September 8, 2018 at 6:47:30 PM UTC-4, Ignazio Di Napoli wrote:
>
> I'd really like to read a reply to Lucio's argument about operator 
> overloading.
>  
> Once we define that:
> 1. a type);
> 2. a==b is the same as a.Equals(b);
> 3. the other comparaison operators are defined using these two (e.g.: a>b 
> is !a.Less(b) && !a.Equals(b));
> 4. a.Index(b) is the same as a[b] and a.Index2(b, c) is the same as a[b:c];
> 5. maybe some more?
> Would we really need contracts and the added complexity in this case? 
> Shouldn't slightly extended interfaces suffice?
>
> E.g.:
>
> type comparer(type T) interface {
> Less(other T)
> }
>
> func min(type T comparer)(a, b T) {
> if a < b {
> return a;
> }
> return b;
> }
>
>

-- 
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] Re: Generics as builtin typeclasses

[Jonathan Amsterdam]

>
>  When is it important to not just express what operations are 
> required for a type, but also to try to rule out some types? 
>

I think the short answer is: numeric code. That's when one thinks about 
which types make sense for an algorithm, not just which operations.

I'm not exactly sure why. It could be because Go doesn't support operator 
overloading. In C++ with concepts, maybe the concept for writing some 
generic math function wants operator+ and operator/, and no one cares that 
that may result in nonsense for some implementations of those operators.

 In Go 1, we write numeric code with specific types: float64 and not int64, 
for instance. Go  insists on conversions between numeric types to keep us 
out of trouble: you can't call func Average(a, b float64) on ints without 
explicitly converting them. It seems natural to want to keep that precision 
and safety, but generalize it.

In Go 1, if we wanted to write a numeric algorithm that worked on, say, two 
slices of floating-point numbers, we'd give it the signature func(x, y 
[]float64). If later we wanted to support float32, we'd have to copy the 
code, or make the caller do an expensive conversion. The same problem would 
happen if the caller defined their own floating-point type (e.g. type 
MyFloat float64).

I think I should be able to say, simply and clearly, that the slice element 
can be any type whose underlying type is float32 or float64. Furthermore, I 
don't want to specify the exact operations my implementation currently 
uses. I may want to change the code to use "-" instead of "+" later, for 
reasons of clarity or numerical stability. I shouldn't have to update the 
contract for that.

contract(t T) { t = 0.0 } might seem to restrict to the types I want, but 
it doesn't; you can assign 0.0 to an integer type. 

contract(t T) { t = 0.5 } is wrong too. It includes complex types.

contract(t T) { float64(t) } also works for ints, so no good.

I believe the answer is 

   contract(t T) { t = 0.5; float64(t) }

but I'm not positive about that. Certainly, very few people who read that 
will immediately understand that T is a type whose underlying type is a 
float.

(And I haven't done the second part, where I add all the valid operators 
for floats.)

Earlier you wrote

> [T]o me it always seems quite clear which type arguments a contract 
allows 
and excludes.  It's exactly the set of types that type check 
successfully.  It's true that sometimes this can be a surprising type, 
but to me that seems just like the fact that it can be surprising 
which types implement an interface. 

I think this example, and the other ones given in this thread, demonstrate 
that this is not "just like" the surprise of which types implement an 
interface. It's more like solving a puzzle, as someone (Axel?) has said.

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

[go-nuts] confused about assignability

[Jonathan Amsterdam]

Consider

type Int int
var y int = Int(3)

The spec says

A value x is assignable to a variable 
 of type T ("x is assignable to T") 
if one of the following conditions applies:


   - x's type V and T have identical underlying types 
   and at least one of V or T is not 
  a defined  type.
  - [other conditions]
   

Here, x's type V is Int, whose underlying type is int, so the underlying 
types are the same. And one of V and T (namely, T, which is int) is not a 
defined type.


So the spec says the assignment should work. But the playground says


cannot use Int(3) (type Int) as type int in assignment


-- 
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] Re: Is it possible to unmarshall Json by selecting the struct from a field in the Json?

[Jonathan Yu]

You can also keep a map between the string form and the reflect.Type to
instantiate, something like https://play.golang.org/p/XCfpjQwumkZ

However, the Go proverb is true: "Reflection is never clear"
https://go-proverbs.github.io/

On Wed, Mar 28, 2018 at 5:58 AM, <gary.willoug...@victoriaplumb.com> wrote:

> Thanks. I read that blog post earlier and presents two different ways of
> handling this. Each maintains a list of switch cases and constants
> respectively so still not entirely dynamic.
>
> I'll probably just go with a switch then.
>
>
> On Wednesday, 28 March 2018 13:25:47 UTC+1, Andrei Tudor Călin wrote:
>>
>> It isn't really possible to do so because there is no nice and type safe
>> way of getting from a string in the JSON to a Go type,
>> and a value of said type. You must write a little bit of extra code.
>>
>> This article: http://eagain.net/articles/go-dynamic-json/ presents a
>> good approach.
>>
>> On Wednesday, March 28, 2018 at 1:46:24 PM UTC+2,
>> gary.wi...@victoriaplumb.com wrote:
>>>
>>> Is it possible to unmarshall Json by selecting the struct from a field
>>> in the Json?
>>>
>>> I'm porting some PHP code to Go and this is something I may have to
>>> approach differently.
>>> Here is the Json:
>>>
>>> [
>>> {
>>> "class": "Domain\\Model\\Message",
>>> "skus": [
>>> "FOO1"
>>> ],
>>> "label": "Lorem",
>>> "text": "Lorem ipsum dolor sit amet.",
>>> }
>>> ]
>>>
>>> In PHP the above Json is decoded into an associative array and I can use
>>> the 'class' field to decode further to an object (dynamically selecting the
>>> object using the 'class' value), like this:
>>>
>>> $obj = $decoded['class']::jsonDeserialize($decoded);
>>>
>>>
>>> assert($obj->label == "Lorem");
>>>
>>> So the above really translates to calling the static method on a
>>> concrete class, like this:
>>>
>>> $obj = Domain\\Model\\Message::jsonDeserialize($decoded);
>>>
>>> Can I do anything similar in Go without using a switch defining separate
>>> unmarshalling for each class?
>>>
>>> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

-- 
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] Go Programming Language Course

[Jonathan Yu]

I develop Go on Windows 10, and it's bearable, but not great. There are
missing features (IIRC, plugins only work on Linux/Mac OS) and the lack of
a C compiler toolchain can cause problems too (e.g. I couldn't install
SQLite as it's a Go binding to C code, and I don't have GCC configured. I
guess I could've spent more time figuring out mingw32 but I just gave up.)

I do think Visual Studio Code and Go (whether on Windows or Linux) is a
decent experience especially for simple programs that might be typical in a
course. That said, Linux experience is probably a good idea for students in
general as that's where the industry seems to be moving (at least in the SF
Bay Area.) Students might do well to have exposure to both as it means
they're not relying on central infrastructure, which might get overloaded,
particularly when it gets close to assignment deadlines.

On Wed, Feb 21, 2018 at 5:51 AM, Dick Seabrook <dick.seabr...@gmail.com>
wrote:

> I'm putting together a 3-credit introduction to the Go programming
> language at
> the community college level. I will create (as a minimum) syllabus,
> outline,
> lecture notes, handouts, assignments, projects, quizzes and final exam. I
> will
> probably start with the Donovan & Kernighan A-W 2015 text.
> Prerequisite: familiarity with personal computers and at least one
> programming
> language, preferably C.
> I'd like to set it up in a shared Linux environment although I'll be
> teaching
> exclusively in Windows 10 labs. Fortunately we've got a large Linux VM on
> campus
> so the Linux base is do-able, however is there any value in teaching Go on
> Windows 10 natively?
>
> Any thoughts or suggestions?
> Thanks,
> Dick S.
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

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

[go-nuts] Re: Proposal: return if any not nil

[Jonathan]

Or just change how gofmt formats if statements where the block is a single 
return statement.

if r, err := os.Open( "blah.text"); err != nil { return nil, err }

Or if parseable:

return r, err if { r, err := os.Open( "blah.txt" ) ; err != nil }

I think the first is better, but I'm happy with Go as it is.

Jonathan

-- 
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] can someone create an example for me of a webpage that can run a bash command ?

[Jonathan Yu]

Hi Dave,

I think what you want is to combine net/http (for the server part) with
os/exec (to invoke bash, though with your example you don't need a shell
and could execute the `ls` command directly). You'd need one or two
handlers; maybe browse this to understand more:
https://golang.org/doc/articles/wiki/

It's not specifically what you were asking, but this might be something
that could be done without Go at all, by emulating a full Linux system
entirely in the browser. For example: https://bellard.org/jslinux/

Cheers,

Jonathan

On Wed, Feb 14, 2018 at 6:56 PM, David Brendlinger <
davidbrendling...@gmail.com> wrote:

> can someone create an example for me of a webpage that can run a bash
> command ?
>
> I would like a index.html that has a button on it.  you hit the button and
> it would do a ls /tmp >> myfile
>
> I am a newby :)
>
> Thank you in advance
>
> Dave
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

-- 
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] Selenium webdriver based testing in Go

[Jonathan Yu]

I've had a lot of success with agouti, though I don't know enough about
Selenium to be sure that it's what you're asking for. I used it to do
browser testing of a rich internet application, with chrome driver.

On Dec 31, 2017 14:56, "Tong Sun"  wrote:

> Hi,
>
> Anyone here ever looked into doing Selenium webdriver based testing in Go?
>
> If anyone has experiences before, I'd like to know your view of the whole
> thing.
> Things come to mind are,
>
> - Do you use Selenium IDE or write Selenium webdriver code directly?
> - Selenium IDE is very helpful, but seems to lack the support for Go.
> Agree? Solution?
> - Of all those Selenium/Webdriver client for Go out there,
>e.g., selenium , & go-selenium
> , just to name only a few,
>have you looked into them before making your choice(s)?
>
> I.e., if anyone has experienced Selenium & Go before, please share your
> experiences/findings,
> which will be very valuable to me, and all others looking into the same
> thing.
>
> Thanks a lot
>
> --
> 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.
>

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

[go-nuts] methods for error

[Jonathan Amsterdam]

Inspired by Rob Pike's recent blog post 
 and 
Dave Cheney's errors package , I wrote down 
some methods that I think all errors should implement. 

The key idea is that an error only needs to implement a particular method 
to buy in to a piece of functionality. The bits of functionality are 
orthogonal. (Cheney's package exemplifies this.) If errors implement the 
right methods, then consumers of errors will have an easier time 
classifying errors, taking action on them, and getting more information 
about them.

I wrote some code  that includes an 
interface, a useful implementation, and some helper methods. But the 
essential point is to agree on method names and the overall approach:

   - For chaining errors, an error should implement ErrorSource() error. 
   Many call this "Cause," but that implies a direction of causality that may 
   not be accurate. (I prefix all the methods with "Error" to avoid collisions 
   with existing methods, so retrofitting is painless.)
   - For additional information, an error should implement ErrorDetails() 
   interface{}. The information can be a stack trace, for example.
   - Error types should be expressed with integer codes. To distinguish 
   different sets of codes, use a unique string identifying the space of 
   codes, like HTTP or gRPC. The method to implement is ErrorCode() (space 
   string, code int). There's a natural reluctance to use numeric codes when 
   you can use the type system to provide a richer experience. But the killer 
   feature of integers is that every programming language has them, so it is 
   easy to pass errors around a polyglot system.



-- 
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] how to do numpy.fromstring in Go ?

[Jonathan Yu]

2017-12-06 10:38 GMT-08:00 Christian LeMoussel <cnh...@gmail.com>:

> I have to write a Python program that uses numpy in GO.
> I have this Python code :
>   prefix = "de98671db1ce0e5c9ba89ab7ccdca6c427460295b8dd3642e9b2bb961723
> 307c57629b1ad37909a863a56965"
>   prefix_np = np.fromstring(prefix[0:64], dtype=np.uint32, count=16)
>   print("prefix_np: {}".format(prefix_np))
>
> Output :
>
> prefix_np: [ 943285604 1680946998 1700999522 1664443696  945906233  929194297 
> 1667523427  878917217  909391666  892940848 1684289634  842282547 845298021  
> 909730402  858928945 1664561203]
>
>
> Some idea how can I do this efficiently in GO ?
>

I guess this would depend on whether this is  a well-defined format; you
might have to port numpy's fromstring to Go? But it should be possible...
If you control the Python side, it might be easier to dump the data as JSON
and import into Go that way.

Is there a library equivalent to numpy in GO?
>

I'm not knowledgeable enough to say, but Go has gonum which has similar
goals to numpy and other data science toolkits:
https://github.com/gonum/gonum

>
>
>
> Thank you for your help
> G
> M
> T
> Détecter la langueAfrikaansAlbanaisAllemandAnglaisArabeArménienAzériBasque
> BengaliBiélorusseBirmanBosniaqueBulgareCatalanCebuanoChichewaChinois
> (Simp)Chinois (Trad)CingalaiCoréenCréole haïtienCroateDanoisEspagnol
> EspérantoEstonienFinnoisFrançaisGalicienGalloisGéorgienGoudjaratiGrec
> HaoussaHébreuHindiHmongHongroisIgboIndonésienIrlandaisIslandaisItalien
> JaponaisJavanaisKannadaKazakhKhmerLaotienLatinLettonLituanienMacédonien
> MalaisienMalayalamMalgacheMaltaisMaoriMarathiMongolNéerlandaisNépalais
> NorvégienOuzbekPanjabiPersanPolonaisPortugaisRoumainRusseSerbeSesotho
> SlovaqueSlovèneSomaliSoudanaisSuédoisSwahiliTadjikTagalogTamoulTchèque
> TeluguThaïTurcUkrainienUrduVietnamienYiddishYoroubaZoulou
> AfrikaansAlbanaisAllemandAnglaisArabeArménienAzériBasqueBengaliBiélorusse
> BirmanBosniaqueBulgareCatalanCebuanoChichewaChinois (Simp)Chinois (Trad)
> CingalaiCoréenCréole haïtienCroateDanoisEspagnolEspérantoEstonienFinnois
> FrançaisGalicienGalloisGéorgienGoudjaratiGrecHaoussaHébreuHindiHmong
> HongroisIgboIndonésienIrlandaisIslandaisItalienJaponaisJavanaisKannada
> KazakhKhmerLaotienLatinLettonLituanienMacédonienMalaisienMalayalamMalgache
> MaltaisMaoriMarathiMongolNéerlandaisNépalaisNorvégienOuzbekPanjabiPersan
> PolonaisPortugaisRoumainRusseSerbeSesothoSlovaqueSlovèneSomaliSoudanais
> SuédoisSwahiliTadjikTagalogTamoulTchèqueTeluguThaïTurcUkrainienUrdu
> VietnamienYiddishYoroubaZoulou
> Fonction Sound est limitée à 200 caractères
> Options : Historique : Commentaires : Donate
> <https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick_button_id=GD9D8CPW8HFA2>
> Fermer
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

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

[go-nuts] Re: ssh session

[Jonathan Pittman]

Elaborate on what you mean by "another place." Do you just need multiple 
sessions within your own program or do you need to pass that connection to 
another program (e.g. a proxy command or shared socket connection)?

Within your program, once you have dialed an ssh connection and have an 
*ssh.Client, you can create multiple new sessions.  The ability to run 
those sessions simultaneously may be limited by the MaxSessionLimit on the 
host which limits the number of concurrent sessions per connection.  You 
will generally be safe if you run them one after the other.

On Monday, December 4, 2017 at 2:56:19 PM UTC-5, Alex Hiltov wrote:
>
> Could somebody explain how can I reconnect (reuse) already opened ssh 
> connection in Go. I'm using x/crypto/ssh ssh.Dial function to dial a 
> connection . Then I can start a new session/ run command but I need to use 
> this opened  ss.dial connection from another place. How can i do this?
>
> Thanx
> Alex
>

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

[go-nuts] Re: Dangers of package renaming

[Jonathan Hall]

Thanks for the reply.  Those are some good considerations.

I'm not excited about retaining a "stub" package in the old location.  I'd 
rather that just redirect, rather than creating two packages.  The 
two-package approach may solve a short-term pain, but I fear it may 
increase long-term confusion.

I wonder what you, or others, would think of using another approach: 
Setting an import comment to the old path, until a version bump.

In other words, I would add import comments to all of the existing packages:

package kivik // import "github.com/flimzy/kivik"

Then I would transfer the package to the new group, keeping the import 
comments in place.  All consumers of the library would therefore be 
required to use the old import path.

At some point in the (near) future, I'd bump the version to 2.0.0, along 
with a renaming of all import paths to:

package kivik // import "github.com/go-kivik/kivik"

The 2.0.0 switch will involve other breaking changes, so this would bundle 
all breaking changes together, while continuing to work for the old import 
path for older versions.

This approach of course assumes that consumers of the library are using a 
vendoring tool with semver support, but this is an assumption I'm willing 
to live with.

Any drawbacks I'm not seeing with this approach?

-- Jonathan

On Saturday, December 2, 2017 at 4:33:06 PM UTC+1, Jonathan Hall wrote:
>
> I maintain an open-source Go package with a few dozen followers.  (
> github.com/flimzy/kivik)
>
> I'm planning to transfer/rename the package to a new organization (new 
> package name to be: github.com/go-kivik/kivik).
>
> I understand that GitHub will maintain a redirect from the old location to 
> the new one, so in theory, old imports will continue working.
>
> But my question is: Are there any dangers I need to consider when making 
> this change, and is there anything I can do to help mitigate such dangers?  
> I ask mainly because I've read of some nightmares related to package 
> renaming (example: 
> https://github.com/sirupsen/logrus/issues/570#issuecomment-313933276), 
> and want to do everything possible to prevent such problems for my own 
> package.  (To be clear: I don't think the Sirupsen problem in particular 
> will affect me, since it's not just a capitalization change).
>
> Keep in mind that the package has sub-packages as a dependencies (i.e. 
> github.com/flimzy/kivik dependson github.com/flimzy/kivik/errors), in 
> case this complicates things.
>
> Thank you,
>
> Jonathan
>
>

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

[go-nuts] Dangers of package renaming

[Jonathan Hall]

I maintain an open-source Go package with a few dozen followers.  
(github.com/flimzy/kivik)

I'm planning to transfer/rename the package to a new organization (new 
package name to be: github.com/go-kivik/kivik).

I understand that GitHub will maintain a redirect from the old location to 
the new one, so in theory, old imports will continue working.

But my question is: Are there any dangers I need to consider when making 
this change, and is there anything I can do to help mitigate such dangers?  
I ask mainly because I've read of some nightmares related to package 
renaming 
(example: 
https://github.com/sirupsen/logrus/issues/570#issuecomment-313933276), 
and want to do everything possible to prevent such problems for my own 
package.  (To be clear: I don't think the Sirupsen problem in particular 
will affect me, since it's not just a capitalization change).

Keep in mind that the package has sub-packages as a dependencies (i.e. 
github.com/flimzy/kivik dependson github.com/flimzy/kivik/errors), in case 
this complicates things.

Thank you,

Jonathan

-- 
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] Re: invitation to gophers.slack.com

[Jonathan Yu]

Go here to request an invite: https://invite.slack.golangbridge.org/

On Fri, Nov 17, 2017 at 7:16 AM, Matteo G. <m.gala...@gmail.com> wrote:

> Hi, I don't understood how I can sign up to ghopers.slack.com. Some
> suggestion?
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

-- 
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] Golang performance benchmarks on arm64 (Qualcomm Centriq 2400)

[Jonathan Yu]

On Thu, Nov 9, 2017 at 6:37 AM, Gerald Henriksen <ghenr...@gmail.com> wrote:

> On Wed, 8 Nov 2017 13:57:03 -0800 (PST), you wrote:
>
> >"Go support for aarch64 is quite disappointing.
>
> >Qualcomm and other ARMv8
> >vendors intends to put significant engineering resources to amend this
> >situation, but really any one can contribute to Go. So if you want to live
> >your mark, now is the time."
>
> I would turn this around and say hardware support for aarch64 is quite
> disappointing, and as a result nobody is interested in developing for
> it (outside of certain companies who can either afford the hardware
> costs or are given the hardware).
>
> If the aarch64 hardware makers want the open source community to
> develop and test for aarch64, then they need to make appropriate
> hardware available to the community at a cost your average open source
> developer can afford.  Yes, it nice the blogger in question was given
> some (likely very expensive) hardware, but that doesn't apply to the
> community in general.
>

Presumably most of the development will be done by companies (such as
CloudFlare) that have a vested interest in a second vendor succeeding,
perhaps because of better performance for specific applications (more
cores, less energy, better price/performance ratio). Large open source
projects (e.g. Debian) will probably get sponsored machines. Smaller
projects would presumably be able to "rent" these processors on one of the
clouds and might receive some sponsorship as well.

>
> [and this is restriced to ARM, POWER has the same issue]
>

I assume you mean "not restricted" to ARM. POWER doesn't seem to have
really taken off (neither ARM at present, but certainly Centriq is
fascinating) despite being opened up (OpenPOWER). I'm not close enough to
either of these communities to speculate as to why this is so.

-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

-- 
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] http server request queue

[Jonathan Yu]

chi includes a middleware for this, see:
https://github.com/go-chi/chi/blob/master/middleware/throttle.go and some
examples here:
https://github.com/go-chi/chi/blob/master/_examples/limits/main.go

I haven't used it myself, but it seems to support having a fixed backlog as
well, which is important for backpressure, see:
https://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/#backpressure

On Sat, Oct 28, 2017 at 6:23 AM, Keith Brown <keith6...@gmail.com> wrote:

> Here is a scenario: a high traffic site which executes costly operations
> (database / filesystem / compute heavy operations). The web server is
> running standard go/http/server.
>
> I would like to handle at most 100 requests and the remainder to queue --
> all while the client (curl) is waiting. Are there tools to throttle the web
> server? And is there a way to view the queue of work?
>
>
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

-- 
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] Handle sub domains in go.

[Jonathan Yu]

I don't use gin (I use chi) but from the docs it seems gin is based on
httprouter, and thus maybe this pattern/example is useful?
https://github.com/julienschmidt/httprouter#multi-domain--sub-domains
(looks very similar to yours, though - only difference is that this example
uses the fully-qualified hostname instead of just the first part)

Chi provides a middleware for doing this:
https://github.com/go-chi/hostrouter - the source code might help you with
what you're doing?
https://github.com/go-chi/hostrouter/blob/master/hostrouter.go

On Fri, Oct 27, 2017 at 3:44 AM, Swati Sharma <swatin...@gmail.com> wrote:

> Hello
> I am working on a project where I need to setup the multiple sub-domains
> with the routes. For routing I am using gin package.  I tried code with two
> sub-domains, but in my case it would be 100 sub-domains. I tried the
> following code for this:
>
> package main
>
> import (
> "github.com/gin-gonic/gin"
> "net/http"
> "strings"
> )
>
> type Subdomains map[string]http.Handler
>
> func (subdomains Subdomains) ServeHTTP(w http.ResponseWriter, r 
> *http.Request) {
> domainParts := strings.Split(r.Host, ".")
>
> if mux := subdomains[domainParts[0]]; mux != nil {
> mux.ServeHTTP(w, r)
> } else {
> http.Error(w, "Not found", 404)
> }
> }
>
> func main() {
> r := gin.Default()
> r2 := gin.Default()
> hs := make(Subdomains)
> hs["admin"] = r
> hs["analytics"] = r2
> r.GET("/ping", adminHandlerOne)
> r2.GET("/ping", adminHandlerOne)
> http.ListenAndServe(":9090", hs)
> }
> func adminHandlerOne(c *gin.Context) {
> c.JSON(200, gin.H{
> "message": "pong",
> })
> }
>
> But I think that this is not good. Is anybody know the proper way to do
> this?
> I tried to do this with loop also, but it did't work for me.
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

-- 
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] Re: How to read multi-page TIFF image?

[Jonathan Pittman]

We have some ideas in common for sure (i.e. storing with upsin/camlistore
and grabbing the embedded previews for display).  Though, my needs go much
further (i.e. being able to process my raw images with Go).  I stick every
RAW image from my D800 in Google Cloud Storage with the plan to eventually
do something like that.  We should discuss this separately at some point.

The biggest issue with the multipage TIFF support being added to the
current tiff package is that the intent was to only support the base
requirements (the first IFD and only the base and some extended tags).  It
might not be a lot of code or trouble to support processing additional
IFDs, but I want to caution against supporting much more than that without
rethinking the API and scope of the package.  The TIFF data structures are
pretty simple, but what you do with the data and how you process the data
in them can get complicated when you start adding support for more tags and
devices.  It is something I really want to see though.

On Mon, Sep 25, 2017 at 11:37 AM, Andrew O'Neill <foolus...@gmail.com>
wrote:

> I'm currently travelling with a Nikon D750. From what I can tell the raw
> images use a single IFD with 2 SubIFDs the main one being the embedded jpeg
> for the thumbnail and the second being the raw image data. If you have
> something to parse the raw image data that would be awesome. I've been
> testing some different storage solutions (upspin, camlistore) and wanted to
> build something that would watch for newly added RAW images and create jpeg
> thumbnails, and various sizes for sharing via blog, twitter, whatever.
>
> On Monday, September 25, 2017 at 3:40:25 PM UTC+2, Jonathan Pittman wrote:
>>
>> Wether a multi-page TIFF uses multiple IFDs or uses one IFD with multiple
>> SubIFDs is implementation dependent.  Though, I think most probably just
>> use multiple IFDs.  The basic structure of an IFD and a SubIFD is
>> essentially the same.  The main difference is where you find their offsets
>> and the offset for the next IFD.  If you want to just grab all of the
>> regular IFDs, that is pretty easy to do.  The "next offset" to the next IFD
>> is at the end of the IFD's structure.  You just go to that next offset and
>> then process the IFD just like you did the first one.  Grabbing SubIFDs
>> requires you to look for the SubIFD tag (330 or 0x014a) inside an IFD and
>> process the value field into a list of offsets values as a []uint32.  There
>> could be one or more offsets.  Keep in mind that with SubIFDs, while the
>> tag ID, its purpose, and format are documented and not intended to be
>> changed, some manufacturers will ignore this and reuse the field for
>> something else.  Sony did this on at least one camera model that I know
>> of.  Most uses I have seen adhere to the original purpose though.
>>
>> If you want to see some (unfortunately) undocumented and very incomplete
>> code for processing the basic data structures of a tiff (i.e. getting IFDs
>> and SubIFDs, but not going as far as processing the actual image data), I
>> posted some code here github.com/google/tiff.  The godoc page
>> <https://godoc.org/github.com/google/tiff> is more useful I think.  I
>> started on this code a while back, but have not had time to revisit it in
>> depth in a while.
>>
>> Andrew, which camera makes and models do you shoot with?  I have a Nikon
>> D200 and a D800.  I started working on model specific data structures for
>> multiple camera models at https://godoc.org/github.com/google/cameraraw.
>> I actually have code to generate those go files based on a TIFF/DNG/RAW
>> file.  It is just not checked in anywhere.
>>
>> On Monday, September 25, 2017 at 7:10:40 AM UTC-4, Tad Vizbaras wrote:
>>>
>>> If you implement decoder I can provide sample multi-page TIFF files to
>>> see if it is working.
>>>
>>> On Sunday, September 24, 2017 at 2:48:50 PM UTC-4, Andrew O'Neill wrote:
>>>>
>>>> A while ago I reading Adobe's doc's on SubIFD's since that is needed
>>>> for decoding Nikon's RAW files. Is this a similar thing or is it just
>>>> reading all the IFD's? I plan to implement a SubIFD decoder for tiff,
>>>> unless someone else has done it.
>>>>
>>>> On Sun, Sep 24, 2017 at 8:21 PM Tad Vizbaras <eta...@gmail.com> wrote:
>>>>
>>>>> Sad.
>>>>>
>>>>> Any chance to add multi page support to this? I am in desperate need
>>>>> for multi-page TIFF support.
>>>>>
>>>>>
>>>>> On Sunday, September 24, 2017 at 9:20:31 AM UTC-4, Guy Allard wrote:
>>>>>>

Re: [go-nuts] Re: How to read multi-page TIFF image?

[Jonathan Pittman]

Wether a multi-page TIFF uses multiple IFDs or uses one IFD with multiple 
SubIFDs is implementation dependent.  Though, I think most probably just 
use multiple IFDs.  The basic structure of an IFD and a SubIFD is 
essentially the same.  The main difference is where you find their offsets 
and the offset for the next IFD.  If you want to just grab all of the 
regular IFDs, that is pretty easy to do.  The "next offset" to the next IFD 
is at the end of the IFD's structure.  You just go to that next offset and 
then process the IFD just like you did the first one.  Grabbing SubIFDs 
requires you to look for the SubIFD tag (330 or 0x014a) inside an IFD and 
process the value field into a list of offsets values as a []uint32.  There 
could be one or more offsets.  Keep in mind that with SubIFDs, while the 
tag ID, its purpose, and format are documented and not intended to be 
changed, some manufacturers will ignore this and reuse the field for 
something else.  Sony did this on at least one camera model that I know of. 
 Most uses I have seen adhere to the original purpose though.

If you want to see some (unfortunately) undocumented and very incomplete 
code for processing the basic data structures of a tiff (i.e. getting IFDs 
and SubIFDs, but not going as far as processing the actual image data), I 
posted some code here github.com/google/tiff.  The godoc page 
 is more useful I think.  I 
started on this code a while back, but have not had time to revisit it in 
depth in a while.

Andrew, which camera makes and models do you shoot with?  I have a Nikon 
D200 and a D800.  I started working on model specific data structures for 
multiple camera models at https://godoc.org/github.com/google/cameraraw.  I 
actually have code to generate those go files based on a TIFF/DNG/RAW file. 
 It is just not checked in anywhere.

On Monday, September 25, 2017 at 7:10:40 AM UTC-4, Tad Vizbaras wrote:
>
> If you implement decoder I can provide sample multi-page TIFF files to see 
> if it is working.
>
> On Sunday, September 24, 2017 at 2:48:50 PM UTC-4, Andrew O'Neill wrote:
>>
>> A while ago I reading Adobe's doc's on SubIFD's since that is needed for 
>> decoding Nikon's RAW files. Is this a similar thing or is it just reading 
>> all the IFD's? I plan to implement a SubIFD decoder for tiff, unless 
>> someone else has done it.
>>
>> On Sun, Sep 24, 2017 at 8:21 PM Tad Vizbaras  wrote:
>>
>>> Sad.
>>>
>>> Any chance to add multi page support to this? I am in desperate need for 
>>> multi-page TIFF support.
>>>
>>>
>>> On Sunday, September 24, 2017 at 9:20:31 AM UTC-4, Guy Allard wrote:

 This package does not appear to support multi-page TIFs.  Decoder 
 initialization only reads the 1st IFD.

 On Friday, September 22, 2017 at 1:49:47 PM UTC-4, Tad Vizbaras wrote:
>
> No problem reading single page TIFF images using: 
> "golang.org/x/image/tiff".
>
> It works great.
>
>
> Question: how to read multi-page scanned TIFFs? How to access pages 2, 3, 
> etc.?
>
>
> -- 
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

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

[go-nuts] Possible bug in golang type checker

[jonathan . hurter]

Hi !

Today i found a weird thing in the Golang type checker.

I have a package with the following architecture:


type A interface {
> D()
> }
>
> type B struct {
> *C
> }
>
> func (t B) NotD() {}
>
> type C struct{
> A
> }
>


And when i did:
 

> var _ A = (*B)(nil)
>

I excpected the Compiler to return me an error like:

 cannot use (*B)(nil) (type *B) as type A in assignment:
>   *B does not implement A (missing D method)
>
>
But the compiler didn't complain at all and let me compile the code.
I can even do some weird things like that:

var a A = (*B)(nil)
> a.D()
>

The compiler will produce a binary without complaining but it panic 
(obviously)

(You can find this example here: https://play.golang.org/p/c8-rNHDqup)

Curiously enough, naming C, will fix the issue (see 
https://play.golang.org/p/VqxCRxu2hi)

Is that a bug in the golang type checker or am i missing something.

Thanks,

Jonathan Hurter

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

[go-nuts] Re: How to break a long code into lines in Golang?

[Jonathan]

Go makes it easy to use intermediates, and the code will be easier to read 
for someone else, possibly years from now.

{
  intervalMS := *Int64Flag_xxIntervalMS
  interval := time.Duration(intervalMS) * time.Millisecond
  elapsed := time.Now().Sub(timeStart)
  time.Sleep( interval - elapsed)
}

or, if you want to do this in several places:

sleepRemainder := func( timeStart time, intervalMS int ) {
  interval := time.Duration(intervalMS) * time.Millisecond
  elapsed := time.Now().Sub(timeStart)
  time.Sleep( interval - elapsed )
}

sleepRemainder( timeStart, Int64Flag_xxIntervalMS )

I've done this even when the code is only used once.  Sometimes it makes 
the code clearer by making the overall structure clearer.

Jonathan

-- 
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] Re: Who wants to use Go to process your camera's raw files?

[Jonathan Pittman]

Unfortunately not from my end.  I have had a lot going on at work and
home.  Time to work on this has escaped me.

I did manage to move my initial prototyping work over to
github.com/google/tiff and update the LICENSE to match the Go license.  So,
this is where we can make changes or blow it all away and start fresh.

I will be at GopherCon this year (and GothamGo) if anyone wants to meet up
and discuss or start hacking on this.

On Tue, Jul 4, 2017 at 11:09 AM, <pierbove...@gmail.com> wrote:

> Any updates on this?
>
> I'm looking at processing RAW images in a server with Go.
>
>
> On Tuesday, July 26, 2016 at 9:36:31 PM UTC-5, Jonathan Pittman wrote:
>>
>> Well me too!  I am looking to see what level of interest there is in the
>> Go community to see this happen.  I am also looking for people who are
>> interested in working on this.
>>
>> Figuring out how to handle this problem for one specific camera's raw
>> files is not too difficult.  Figuring out how to do this to handle the
>> majority of cases requires a bit more work.
>>
>> To be clear, I am wanting a pure Go solution that is better thought out,
>> better laid out, and better to use than the existing C/C++ options.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/60WthPS_TXg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] minimum b.N

[jonathan . gaillard]

I don't think there is a way, but is there a way to specify a minimum b.N? 
So we have a bunch of benchmarks, but some are benchmarking things that 
take milliseconds and some seconds. So specifying benchtime like 30s makes 
the whole build run too slow.

-- 
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] New fully featured bash completion for go - written in go

[Jonathan Yu]

Nifty! Do the bash completion scripts need to be dynamically regenerated? I
guess so for some of the features like completing on package names.

It seems useful to have some Go completions (e.g. go in == go install)
available as part of distro packages.

On Sat, May 13, 2017 at 1:29 AM, Eyal Posener <pose...@gmail.com> wrote:

> Simple to install (Assuming GOPATH and PATH are correct):
>
> go install github.com/posener/complete/gocomplete
> gocomplete -install
>
>
> Features:
>
>- Complete go command, sub commands and flags.
>- Complete package names, .go files and ellipsis when necessary.
>- Complete test names after -run flag!
>
> Works with bash / zsh shells
>
> This is also a package, that enables writing bash completion scripts, or
> add them to an existing go program.
>
> Please, open issues, contribute and star!
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

-- 
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] How to get size of http request/stream size transferred over wire?

[Jonathan Yu]

Have you considered an external tool, like Wireshark or tcpdump? (The
latter can capture pcap files for processing with the former)

On Sat, May 13, 2017 at 12:04 AM, <mujtaba.altame...@gmail.com> wrote:

> I'm trying to make a comparison between http1.x and http2's long-polling.
> Since headers are only sent once in http2, I'm trying to figure out the
> difference in the size of the data transferred over the wire. Is there a
> way to do that?
>
> Thanks
>
> --
> 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.
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

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

[go-nuts] using GitHub Pages for import paths

['Jonathan Amsterdam' via golang-nuts]

What do you all think about using GitHub Pages URLs for import paths?

I got to thinking about that because Go is moving towards having real
dependency management, and it looks like the repo is going to be the unit
of versioning. That implies that repo boundaries are going to be changing a
lot in the next year or two, as people split up multi-package repos in
order to version packages separately. If you use the repo URL directly as
an import path (e.g. "github.com/jba/gorepo/pkg1"), then splitting the repo
will change the import path.

To avoid changing the import path, you can use the import path redirection
 feature (a.k.a. vanity
paths). I can have import paths "jba.org/pkg1" and "jba.org/pkg2" both
point to "github.com/jba/gorepo" initially. If I later decide to have
separate repos for pkg1 and pkg2, I can keep the same import paths and just
change where they point. To use import path redirection, though, you need
both a domain and a server to host it. Many people already have that, but
if you don't it would be nice if there were a zero-effort way to get one.

I realized that GitHub Pages seems like a good choice for that. In case
you're not familiar, GitHub gives you a free static site for your username
or org (jba.github.io, in my case) that you have total control over, so you
can embed the necessary meta tag to make import path redirection work. The
URL is not ideal, but it's no worse than the raw repo URL. I'd guess the
availability of the site is the same or only a little less than the
availability of the repo itself. There are limits on the site, notably 100G
bandwidth/month, but unless you're hosting a lot of content or have a very
popular package, you're unlikely to hit that.

Does anyone already do this? Are there downsides that I'm missing?

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

[go-nuts] Re: ...interface{} vs interface{} + reflection

[Jonathan Hall]

Nice find wrt: mgo. That is a good analogy.

And thanks for your input.  That is a good observation that it could also 
save some internal conversion.

-- Jonathan

On Tuesday, May 2, 2017 at 8:12:39 PM UTC+2, Jonathan Hall wrote:
>
> I have a public API that takes `...interface{}` as an argument.  (For 
> reference: https://godoc.org/github.com/flimzy/kivik#DB.BulkDocs )
>
> I'm considering changing this to instead take `interface{}` as an 
> argument, then using reflection to:
>
>   - Validate that the underlying type is an array
>   - Convert to `[]interface{}` before using it internally
>
> The reason I'm considering the change is that the normal use-case for the 
> function is on an array of specifically-typed documents, and converting to 
> `[]interface{}` before every call is cumbersome, and redundant ~95%+ of the 
> time.
>
> I'm wondering if I might be overlooking any obvious drawbacks to this 
> approach.  Thus far, my hesitation comes from the following facts:
>
> - Using reflection to check that an argument is an array seems sloppy 
> (although I've seen it before). It loses all benefits of compile-time 
> checking
> - Using reflection for the conversion is presumably slower than doing the 
> conversion in the caller.
>
> Are there other pros or cons I'm not considering that I should take into 
> account when deciding how to proceed?
>
> Much thanks,
>
> -- Jonathan
>
>

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

[go-nuts] ...interface{} vs interface{} + reflection

[Jonathan Hall]

I have a public API that takes `...interface{}` as an argument.  (For 
reference: https://godoc.org/github.com/flimzy/kivik#DB.BulkDocs )

I'm considering changing this to instead take `interface{}` as an argument, 
then using reflection to:

  - Validate that the underlying type is an array
  - Convert to `[]interface{}` before using it internally

The reason I'm considering the change is that the normal use-case for the 
function is on an array of specifically-typed documents, and converting to 
`[]interface{}` before every call is cumbersome, and redundant ~95%+ of the 
time.

I'm wondering if I might be overlooking any obvious drawbacks to this 
approach.  Thus far, my hesitation comes from the following facts:

- Using reflection to check that an argument is an array seems sloppy 
(although I've seen it before). It loses all benefits of compile-time 
checking
- Using reflection for the conversion is presumably slower than doing the 
conversion in the caller.

Are there other pros or cons I'm not considering that I should take into 
account when deciding how to proceed?

Much thanks,

-- Jonathan

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

[go-nuts] Re: Best practice for client API with both context-aware and non-context-aware methods

[Jonathan Hall]

Thank you, everyone, for the feedback. You've validated my thoughts on the 
matter.  I just removed all of the non-Context methods from my library, and 
am much happier with it already.

Cheers.

On Saturday, April 15, 2017 at 2:49:55 AM UTC+2, Jonathan Hall wrote:
>
> I'm working on a client client API, and am accepting a `context.Context` 
> argument as the first argument to each function.
>
> However, for ease of use, I'm also providing non-context aware versions of 
> each method.  So my API looks roughly like:
>
> FooContext(ctx context.Context, args...)
> Foo(args...)
>
> where Foo(args...) just calls FooContext(context.Background(), args...).
>
> Multiply this times about 25 methods across a few different types, and I 
> have a very cluttered package (and godoc).
>
> I borrowed this approach from the `sql` package.  But the sql package has 
> about half as many methods, so it seems less cluttered. It also has to 
> retain backward compatibility with context-unaware code.
>
> Is there anything like a "best practice" in this area, given that (unlike 
> the `sql` package) I have no backward compatibility to maintain?
>
> Some options I've considered:
>
> 1. Keep things as they are.
> 2. Only expose the 'Context' versions of my methods (and drop the 
> 'Context' suffix)
> 3. For each type, add a single `Background()` method, which returns a 
> clone type, that uses a background context. So `client.Foo()` becomes 
> `client.Background().Foo()`.  This doesn't reduce clutter, but it helps to 
> organize it on the godoc page, by grouping all the Context-aware methods 
> together, and the unaware together.
>
> I think I'm leaning toward #2.  I imagine a fair number of Go newbies will 
> find the context argument to be "strange", but I hope documentation will 
> fix that.
>
> Are there other alternatives I should consider?
>
> Much thanks,
>
> Jonathan
>
>

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

[go-nuts] Best practice for client API with both context-aware and non-context-aware methods

[Jonathan Hall]

I'm working on a client client API, and am accepting a `context.Context` 
argument as the first argument to each function.

However, for ease of use, I'm also providing non-context aware versions of 
each method.  So my API looks roughly like:

FooContext(ctx context.Context, args...)
Foo(args...)

where Foo(args...) just calls FooContext(context.Background(), args...).

Multiply this times about 25 methods across a few different types, and I 
have a very cluttered package (and godoc).

I borrowed this approach from the `sql` package.  But the sql package has 
about half as many methods, so it seems less cluttered. It also has to 
retain backward compatibility with context-unaware code.

Is there anything like a "best practice" in this area, given that (unlike 
the `sql` package) I have no backward compatibility to maintain?

Some options I've considered:

1. Keep things as they are.
2. Only expose the 'Context' versions of my methods (and drop the 'Context' 
suffix)
3. For each type, add a single `Background()` method, which returns a clone 
type, that uses a background context. So `client.Foo()` becomes 
`client.Background().Foo()`.  This doesn't reduce clutter, but it helps to 
organize it on the godoc page, by grouping all the Context-aware methods 
together, and the unaware together.

I think I'm leaning toward #2.  I imagine a fair number of Go newbies will 
find the context argument to be "strange", but I hope documentation will 
fix that.

Are there other alternatives I should consider?

Much thanks,

Jonathan

-- 
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] gomock - why do recorder methods use interface{}?

[Jonathan Yu]

Thanks so much for your answer, Julian, that makes total sense! I guess the
examples I've seen so far are missing these more "advanced" use cases :)

Appreciate the quick and informative reply.

On Wed, Apr 5, 2017 at 4:13 PM, Julian Phillips <jul...@quantumfyre.co.uk>
wrote:

> On 05/04/2017 18:06, Jonathan Yu wrote:
>
>> Hi everyone,
>>
>> I've been using gomock to generate mock objects (in source mode), and it's
>> been pretty great - way better than maintaining similar code on my own.
>> One
>> thing that I find curious, though, is that expectations are recorded using
>> a generic interface{} type, rather than the original type.
>>
>> For example, in the sample mock_user.go
>> <https://github.com/golang/mock/blob/master/sample/mock_user/mock_user.go
>> >
>> file, we have:
>>
>> func (_m *MockIndex) Anon(_param0 string) {
>> _m.ctrl.Call(_m, "Anon", _param0)
>> }
>>
>> func (_mr *_MockIndexRecorder) Anon(arg0 interface{}) *gomock.Call {
>> return _mr.mock.ctrl.RecordCall(_mr.mock, "Anon", arg0)
>> }
>>
>> Does anyone know why the Recorder interface is generated with interface{}?
>> Doesn't this mean that we lose type safety when defining expectations?
>> After all, you can do: mock.EXPECT().Anon(123) even though the method must
>> be called with a string parameter, right?
>>
>
> Because you _don't_ have to use a value of the appropriate type when
> setting up the expectations, e.g.:
>
> "mock.EXPECT().Anon(gmock.Any())" or "mock.EXPECT().Anon(gomock.Not
> ("invalid"))"
>
> in fact "mock.EXPECT().Anon("123")" is actually a shortcut for
> "mock.EXPECT.Anon(gomock.Eq("123"))"
>
> (see https://godoc.org/github.com/golang/mock/gomock#Matcher)
>
> HTH,
>
> --
> Julian
>



-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

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

[go-nuts] gomock - why do recorder methods use interface{}?

[Jonathan Yu]

Hi everyone,

I've been using gomock to generate mock objects (in source mode), and it's
been pretty great - way better than maintaining similar code on my own. One
thing that I find curious, though, is that expectations are recorded using
a generic interface{} type, rather than the original type.

For example, in the sample mock_user.go
<https://github.com/golang/mock/blob/master/sample/mock_user/mock_user.go>
file, we have:

func (_m *MockIndex) Anon(_param0 string) {
_m.ctrl.Call(_m, "Anon", _param0)
}

func (_mr *_MockIndexRecorder) Anon(arg0 interface{}) *gomock.Call {
return _mr.mock.ctrl.RecordCall(_mr.mock, "Anon", arg0)
}

Does anyone know why the Recorder interface is generated with interface{}?
Doesn't this mean that we lose type safety when defining expectations?
After all, you can do: mock.EXPECT().Anon(123) even though the method must
be called with a string parameter, right?

Jonathan

-- 
Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>,
Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>,
Facebook <https://facebook.com/jawnsy>
*“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* —
Samuel Beckett, Worstward Ho (1983)

“In an adaptive environment, winning comes from adapting to change by
continuously experimenting and identifying new options more quickly and
economically than others. The classical strategist's mantra of sustainable
competitive advantage becomes one of serial temporary advantage.” — Navigating
the Dozens of Different Strategy Options
<https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options>
 (HBR)

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

[go-nuts] 1.8.1 release time frame

[jonathan . gaillard]

Anyone know if there is a plan for the 1.8.1 in terms of time? It seems to 
have issues building up on it.

-- 
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] reading/writing after http.Handler returns

[jonathan . gaillard]

Yes and I'll wait for that change, thanks!

On Friday, March 3, 2017 at 2:01:25 PM UTC-8, bradfitz wrote:
>
> I'm not sure I understand what the bug report here is.
>
> Is this https://github.com/golang/go/issues/16100 ?
>
>
> On Thu, Mar 2, 2017 at 3:06 PM, <jonathan...@gmail.com > 
> wrote:
>
>> A few weeks ago we implemented a context that given some readClosers and 
>> writeClosers would track if any were idle and eventually cancel the 
>> context. We use this for handlers in our server.
>> We seem to be having a crash though where we are effectively returning 
>> from a handler, and yet a read/write on a resp.Body might still be blocked 
>> I remember @bradfitz saying this was the only way to get out of the 
>> blocked read/write, should it be causing a panic (from inside the http pkg) 
>> if there is a read/write after the handler returns?
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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