Re: [go-nuts] [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

2020-08-28 Thread Tyler Compton
Thanks Jan, this is very exciting! I'm looking forward to an opportunity to
use this.

On Wed, Aug 26, 2020 at 2:51 PM Jan Mercl <0xj...@gmail.com> wrote:

> From the change log (https://godoc.org/modernc.org/sqlite#hdr-Changelog)
>
> 2020-08-26 v1.4.0:
>
> First stable release for linux/amd64. The database/sql driver and its
> tests are CGo free. Tests of the translated sqlite3.c library still require
> CGo.
>
> $ make full
>
> ...
>
> SQLite 2020-08-14 13:23:32
> fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
> 0 errors out of 928271 tests on 3900x Linux 64-bit little-endian
> WARNING: Multi-threaded tests skipped: Linked against a non-threadsafe Tcl
> build
> All memory allocations freed - no leaks
> Maximum memory usage: 9156360 bytes
> Current memory usage: 0 bytes
> Number of malloc()  : -1 calls
> --- PASS: TestTclTest (1785.04s)
> PASS
> ok  modernc.org/sqlite  1785.041s
> $
>
> --
> 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/CAA40n-XnjDzZnc31UOBn-gHoueT10FrvLCyZh9c8VK7K8ObKjg%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/CAA%3DXfu2rU1BNhu3suy5Jum0LQzEb2tKx%2BXgg_tdY6rA5vnTC1A%40mail.gmail.com.


Re: [go-nuts] A few thoughts on type parameters

2020-08-05 Thread Tyler Compton
On Wed, Aug 5, 2020 at 1:07 AM Jan Mercl <0xj...@gmail.com> wrote:

> It's not supposed to be anything special whatsoever. Just like number
> zero or an empty set is not some kind of an exception. It's just you
> cannot have any reasonable set theory without it.
>

I think it's fair to say that `interface{}` is somewhat special in practice
because it acts as an escape hatch from the type system when necessary. No
other interface is capable of being satisfied by values of all types. I
assume that the `error` interface is pre-declared because it's a very
common interface used across almost all Go code. If `interface{}` is to
become even more common than it is thanks to generics, I think it could be
reasonable to follow the same thinking.

Go programmers do avoid casting because Go has no casting. That word
> or its stem doesn't even appear in the language specs.
>

Something tells me you knew Carla was referring to type assertions.

-- 
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/CAA%3DXfu0c-BqTt6vOjbE9ezur0nNNFCSBhgs%3DPFrEUBPASziinw%40mail.gmail.com.


Re: [go-nuts] Calling methods from inside a function in same package

2020-07-21 Thread Tyler Compton
I think I'm very likely misunderstanding your question. Would you mind
providing more detail?

You can definitely call methods within a function, even if they're defined
in the same package. In this example, I call a method from the type "myInt"
in the main function: https://play.golang.org/p/AAjVZCncUFJ


On Tue, Jul 21, 2020 at 9:51 AM Rudra  wrote:

> Hi,
> One can call global function of same package from inside a function, But I
> am curious if I can call a method from inside a function?
>
> --
> 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/cc1869a9-d6a2-4a2f-890d-d728439fa4c0n%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/CAA%3DXfu0V2BMnfBS6TAus2yk4XKob2d9WCH8qiJ3y-8bZis-8Zw%40mail.gmail.com.


Re: [go-nuts] Go 2 review process

2020-07-19 Thread Tyler Compton
I had forgotten about the multidimensional slices proposal. That's a very
good counter-example.

On Sun, Jul 19, 2020 at 4:12 AM Ian Davis  wrote:

> On Sun, 19 Jul 2020, at 2:08 AM, Ian Lance Taylor wrote:
> > On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton 
> wrote:
> > >
> > > I'm beginning to think that community members (like myself) can't
> reasonably be expected to put in the necessary effort to champion a sizable
> language change. I think it was Ian who made multiple generics draft
> proposals just to reject them himself, then Ian and Robert Griesemer spent
> more untold hours writing the contracts draft design only to have that
> rejected as well. For people outside the core Go team, these probably would
> have been unpaid hours. It's hard to justify spending that kind of time
> when there's such a high chance that the proposal may not amount to
> anything. I think it's for this reason that community proposals are usually
> nowhere near as fleshed out as the draft proposals we've been getting from
> the core team.
> >
> > In fairness, though, there is no language change proposal that is as
> > large as generics.  The changes that were made in recent releases were
> > much smaller.  (And, for what it's worth, they did not all come from
> > Googlers; e.g., https://golang.org/issue/12711,
> > https://golang.org/issue/19308, https://golang.org/issue/29008.)
> >
>
> I think the multidimensional slices proposal (
> https://github.com/golang/go/issues/6282 and several spawned from there)
> is an example of a major proposed change that the community put great
> effort into with multiple detailed specifications. There is an asymmetry of
> time and expertise at play here. I suspect many people would use and
> benefit from native matrices in Go but the number of people with the
> necessary skills to design the spec and the amount of available time to
> devote to it is vanishingly small.
>
> We need a way for knowledgable experts to be able to take a sabbatical or
> similar to spend time refining and guiding their proposal with the Go team.
> Is this something that the Go project or another corporate sponsor could
> help with?
>
> 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/37ed3f4e-460f-48b6-a636-61d3eadc5c8a%40www.fastmail.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/CAA%3DXfu3J%3Dfg9WxCfODoJ7NUagXfqm8e7SkgFVNNSOkAFd4Bazg%40mail.gmail.com.


Re: [go-nuts] Go 2 review process

2020-07-18 Thread Tyler Compton
I'm beginning to think that community members (like myself) can't
reasonably be expected to put in the necessary effort to champion a sizable
language change. I think it was Ian who made multiple generics draft
proposals just to reject them himself, then Ian and Robert Griesemer spent
more untold hours writing the contracts draft design only to have that
rejected as well. For people outside the core Go team, these probably would
have been unpaid hours. It's hard to justify spending that kind of time
when there's such a high chance that the proposal may not amount to
anything. I think it's for this reason that community proposals are usually
nowhere near as fleshed out as the draft proposals we've been getting from
the core team.

There are some incredibly talented and persistent gophers out there and I
don't mean to discourage them. This is just my observation from the
community proposals I've read.

On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:

> I have just read
> https://github.com/golang/go/issues/33892#issuecomment-659618902 and
> since it was posted on a closed issue I wanted to comment a bit more.
>
> I subscribed to this issue and read the updates for both the Go2 proposals
> as well as the Go1 proposals and I enjoy reading them.  I understand the
> reasoning behind wanting to do less here but I do belive there are some
> downsides as well.
>
> One reason I read these every week is that it gives people outside of the
> Go team an insight into the thought process and the reasoning of
> decisions.  Also feedback on these changes hopefully should help to refine
> future requests.  I am really afraid that just "ignoring" requests
> continues or goes back to the idea that  that Go is not a community
> language and that the only ideas and changes can come from Google employees
> (or past employees in the case of bradfitz).  The transparency here was
> awesome and I am very sad to see it go away.
>
> I hope there is some other middle ground or at least some details around
> what will go into hand picking?  For the non-picked proposals will they
> just remain open for some undetermined amount of time?  Will they just be
> closed?  Is feedback on these still expected?   Maybe the real solution is
> just to meet up less?  Maybe once a month or even once a quarter vs every
> week?
>
> Thank you,
>
> Brandon
>
> --
> 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/6e012c05-24ce-49cf-a8f2-b8b6f3f543ffo%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/CAA%3DXfu1KjOU0tzp_nWpV1a_qcFF3XNXs5AB4gsavhtHHPzmz9w%40mail.gmail.com.


Re: [go-nuts] the go archive size must be smaller?

2020-07-16 Thread Tyler Compton
I think something unfortunate happened to your diagram. On Gmail, I see an
 tag with a huge amount of base64 encoded text, and on Google Groups I
don't see anything at all. It may work better to upload the image to a
hosting service like Imgur and link to it.

On Thu, Jul 16, 2020 at 9:47 AM yangw...@gmail.com 
wrote:

> This diagram is the archive size of the go release package.
>
> What's this in those increase package size ?
> Maybe we can reduce the archive size in future.
>
> --
> 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/e59710cd-aa23-483a-a8ad-2c8d8e9e9eaan%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/CAA%3DXfu3szRezYB51TB90eAhsHENWeZ_5ymEFBzX-z3D1d5mqbA%40mail.gmail.com.


Re: [go-nuts] [generics] Syntax feedback

2020-06-30 Thread Tyler Compton
Hi Andrey,

Unfortunately, I don't believe I can edit mailing list posts even on the
Google Groups page. Sorry to have missed your post originally!

On Sun, Jun 28, 2020 at 1:09 PM Andrey T. 
wrote:

> Tyler,
> May I humbly suggest
> https://groups.google.com/d/msg/golang-nuts/W3fSnH0w1G0/JbMkJrKICAAJ for
> an additional item for your list?
>
> Thank you very much,
>   Andrey
>
> On Saturday, June 27, 2020 at 11:46:23 AM UTC-6, Tyler Compton wrote:
>>
>> Hi Rob,
>>
>> This topic has been discussed many times on this list, so it's probably
>> best to look at and post in one of those threads. Let me take this chance
>> to collect as much information about this issue as I can in a single post.
>> Unfortunately, discoverability can sometimes be hard on mailing lists so
>> I don't blame you for not seeing all these.
>>
>> Responses on the subject:
>> Design draft talking about alternative syntax:
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
>> Ian's justification for taking a wait-and-see approach to this syntax
>> issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q
>>
>> Threads:
>> Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
>> Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
>> Use "::" and other suggestions:
>> https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
>> Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
>> Use "<>" before the name of the type being defined:
>> https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
>> Put type parameters in the regular arguments list with a ":type" suffix:
>> https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
>> Use "<>", with some kind of additional syntax to make parsing easier:
>> https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
>> Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
>> Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
>> Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
>> No specific suggestion:
>> https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8
>>
>> --
> 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/32da9686-d144-4d35-924f-b2bb1de7d9b3o%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/32da9686-d144-4d35-924f-b2bb1de7d9b3o%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/CAA%3DXfu2-F-TCVQs%2Boskgz54pN6noXTkdtnzZt3r7Aezwe-oBOw%40mail.gmail.com.


Re: [go-nuts] [generics] Syntax feedback

2020-06-27 Thread Tyler Compton
Hi Rob,

This topic has been discussed many times on this list, so it's probably
best to look at and post in one of those threads. Let me take this chance
to collect as much information about this issue as I can in a single post.
Unfortunately, discoverability can sometimes be hard on mailing lists so I
don't blame you for not seeing all these.

Responses on the subject:
Design draft talking about alternative syntax:
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
Ian's justification for taking a wait-and-see approach to this syntax
issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q

Threads:
Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk
Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk
Use "::" and other suggestions:
https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0
Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI
Use "<>" before the name of the type being defined:
https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34
Put type parameters in the regular arguments list with a ":type" suffix:
https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM
Use "<>", with some kind of additional syntax to make parsing easier:
https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g
Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ
Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0
Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg
No specific suggestion:
https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8


On Sat, Jun 27, 2020, 05:38 Rob Reid  wrote:

> Hi team,
>
> I wanted to provide some feedback on the syntax used in the generics
> proposal.
>
> When I first opened the Go 2 playground, it took me a while to realise
> that (type T) was a generic parameter and not a function parameter and that
> (s []T) was a function parameter and not a return parameter):
>
> func Print*(type T)(s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
> I think this would start to look more confusing when there are return
> values (either single or multiple):
>
> func Something*(type T)(s []T) (T, T)*
>
> I think another character would server to improve the readability of the
> Print function in this example and hopefully prevent the time required to
> grok a generic function to someone who has not seen one in Go before:
>
> func Print*(s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
> func Print*[type T](s []T)* {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
>
> Cheers,
>
> Rob
>
> --
> 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/CA%2Bcy9cUuJqOWWwi4m-MSp6gxKLGC4oFNn6y1zYJgN0Aac31sFg%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/CAA%3DXfu2VxFv9DeBhpX1F6urHHTQLxka82P4JAZuQWuRQCsDfRA%40mail.gmail.com.


Re: [go-nuts] Slices and inconsistency

2020-06-26 Thread Tyler Compton
On Fri, Jun 26, 2020 at 10:52 AM David Riley  wrote:

> Also, to this specific point: this exact approach, as with much of Go,
> embodies the Bell Labs approach to design (for better or for worse, and
> with good reason).  Sometimes we have to live with the artifacts of
> evolution.
>

One interesting counterexample here is the GC and scheduler, which take on
a huge amount of complexity in the implementation to create a dead-simple
interface. It seems like Go is willing to take a worse-is-better approach
when the amount of interface complexity is relatively small.

-- 
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/CAA%3DXfu3xWV94g5smX%3D6kk3QD9fzZN_nhwqF0XykVsmUBDKLTLw%40mail.gmail.com.


Re: [go-nuts] How I can translate this shell command to golang code?

2020-06-22 Thread Tyler Compton
I just want to highlight an easy mistake to make here. One might expect to
be able to run something like this:

exec.Command("echo", "-n", "123456", "|", "dmtxwrite", "-s", "16x48", "-o",
"image.png")

But, as you might have found, this doesn't work. This is because the pipe
"|" is an operator implemented by shells like sh and bash. As mentioned in
the overview of the os/exec package, the package never invokes your shell
automatically, so operators like the pipe operator are not available by
default. Jan's answer works because it invokes the shell explicitly to run
your command.

-- 
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/CAA%3DXfu0YtHNT01vV1JxvpaORfaBCNMLdSYz2LBVpZZHXwNBt3Q%40mail.gmail.com.


Re: [go-nuts] Re: [generics] I think it's better have higher perfomance than lower compiling time

2020-06-20 Thread Tyler Compton
The idea of having development and release compilation modes sounds
appealing at first, though I'm a bit skeptical about how it would turn out.
This would mean that, during development, you wouldn't have a full
understanding of the performance characteristics of your program.
Admittedly, that's not something you *always* care about, but when you do
care you'll have to deal with slow compilation times.

I've found that in C++ certain memory safety bugs will only rear their ugly
head after a certain compiler optimization level, meaning that these bugs
can be missed during development. Go's memory safety would probably make
this significantly less of a problem, but it still concerns me somewhat.

On Fri, Jun 19, 2020 at 6:46 PM David Skinner 
wrote:

> I remember going on a two-hour lunch break at a Cajun restaurant and
> returning to my office to discover that my precompiled C++ headers were
> still compiling. I really love that Go compiles quickly and links quickly.
>
> The day comes when code needs to ship, final compile, and final quality
> control tests,  why not have a final build that compiles quite slowly and
> optimizes to the max. There is no need to do either/or and compromise, just
> do both.
>
> On Friday, June 19, 2020 at 12:23:46 PM UTC-5, Ronald Davilla wrote:
>>
>> Just if perfomance will decrease with every release/version, it'd be not
>> really good, and it's might be necessary to pay more attention to this
>>
> --
> 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/fd72210d-5a04-4be3-b51c-50b8313bf3dao%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/CAA%3DXfu1mBzN6YJJLtAOb1ZBPuDgXoCDzuG34x5XGPwTk1u-q8A%40mail.gmail.com.


Re: [go-nuts] Go has confusing pointers

2020-06-19 Thread Tyler Compton
>
> c is of type *Count (pointer to Count), surely?
>

Yes, my mistake! Thank you for the correction.

-- 
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/CAA%3DXfu3e__kHGcgeAHzZ25jHW1rODpmj_p71yuGeef_yjXeC5g%40mail.gmail.com.


Re: [go-nuts] Go has confusing pointers

2020-06-19 Thread Tyler Compton
>
>  *c = *c + 1 //why use *c and not just c, based on (c *Count) c is already
> a pointer?
>

In Go (as well as other languages like C) '*' plays two roles. When used
with a type like in "c *Count", it tells you that c is a pointer to a Count
object. When used on a variable, like "*c + 1", it dereferences the
pointer. In other words, "*c + 1" gets the value that "c" is pointing to
and adds one to that value.


> why cast to int, c is already of type int?
>

In this case, c is of type Count, not int. When you define a type in Go,
you're defining a new distinct type, not an alias to the underlying type.
The Count type is distinct from int, even though it's based on int.

-- 
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/CAA%3DXfu2GL8oLmpjLcoVh8uJu8m4GFJdSh7SfhbvFy%3D9%2BtVwQDQ%40mail.gmail.com.


Re: [go-nuts] [generics] Simplification: Methods refer to original type parameters instead of re-specifying each time

2020-06-17 Thread Tyler Compton
I think this syntax could get confusing when embedded fields is added to
the mix:

type MyStruct(type T) struct {
T
}

func (ms *MyStruct) MyMethod(t ms.T) {
ms.T =  t
}

In this example. ms.T means two very different things depending on where
they are used.

On Wed, Jun 17, 2020 at 3:45 AM Randall O'Reilly 
wrote:

> You could save a fair amount of typing and eyestrain by not replicating
> the type params for types, in their methods:
>
> type Vector(type T) []T
>
> func (v *Vector) Push(x v.T) { *v = append(*v, x) }
>
> 
>
> type Map(type K, V) struct {
> root*node(K, V)
> compare func(K, K) int
> }
>
> func (m *Map) InOrder() *Iterator(m.K, m.V) {
> type kv = keyValue(m.K, m.V) // convenient shorthand
> sender, receiver := chans.Ranger(kv)()
> var f func(*node(m.K, m.V)) bool
> ...
> }
>
> Could also just have the bare type param name without the field-like
> specifier (e.g., K, V instead of m.K, m.V) but that makes it less obvious
> what K and V are -- m.K makes it clear that K is something I can find if I
> look at the definition of the type of m.
>
> This also enforces consistent naming of type parameters across all methods.
>
> - Randy
>
> --
> 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/2605713E-73F3-4332-911D-D41EAE4DAF6A%40gmail.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/CAA%3DXfu0YzwH8XYM-QOqbnm3YC_WA8Jce_jnzOS4YhP41FjwTKw%40mail.gmail.com.


Re: [go-nuts] [generics] is generics with constrain needed ?

2020-06-17 Thread Tyler Compton
The reason why implicit conversions from []Foo to []Stringer isn't
supported is because Foo and Stringer have different in-memory
representations. Converting from a slice of one to a slice of another would
be more expensive than one would expect an implicit conversion to be. At
least, this is my understanding as to why.

On Wed, Jun 17, 2020 at 3:22 AM Miguel Angel Rivera Notararigo <
ntr...@gmail.com> wrote:

> Allowing this implicit conversion would be a bad thing? because it works
> like generics without any new syntax.
>
> Also, I found this a little messy
>
> type Ordered interface {
>   type int, int8, int16, int32, int64,
>   uint, uint8, uint16, uint32, uint64, uintptr,
>   float32, float64,
>   string}
>
>
> Why not after interface?
>
> type Ordered interface type {
>   int, int8, int16, int32, int64,
>   uint, uint8, uint16, uint32, uint64,
>   byte, rune, uintptr,
>   float32, float64,
>   string,}
>
>
> Sorry, I am pretty new to this, so probably the answers might be really
> obvious 
>
> On Wed, Jun 17, 2020 at 4:37 AM David Anderson  wrote:
>
>> The non-generic form _only_ accepts an argument of type []Stringer. If
>> you have a []Foo, where Foo implements Stringer, that's not good enough.
>> You will have to construct a []Stringer explicitly, and copy each Foo into
>> that []Stringer. This is a fairly common gotcha with Go, where folks expect
>> the implicit conversion to happen.
>>
>> OTOH, the generic form will accept []Foo directly, since Foo satisfies
>> the Stringer constraint.
>>
>> - Dave
>>
>> On Wed, Jun 17, 2020 at 1:20 AM Christophe Meessen <
>> christophe.mees...@gmail.com> wrote:
>>
>>> Reading the document "Type parameters - Draft desing" of June 16, 2020 (
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md),
>>> I wonder if these two following function definitions are not equivalent and
>>> thus interchangeable
>>>
>>> func Stringify(type T Stringer)(s []T) (ret []string)
>>>
>>> func Stringify(s []Stringer) (ret []string)
>>>
>>> If the constrain is an interface, wouldn’t it be the same as to use the 
>>> interface as type ? How would it be different ?
>>>
>>> --
>>> 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/3b758827-2d14-4769-bf94-95cf60a06b1bo%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/CAMx%2Br7Vc9pLY63qJg1ek4ZrYq8YMyJFOLwzN5aLA6T8nho16Ww%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/CAF9DLCm%3D0DSjRk2quhh%3D3L_eUH9%2BuxPXp6-8mzh%3DjZ0csy9rwQ%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/CAA%3DXfu1_0stPaP0U%3Dv91%3DWcyvRiWO0Pg12cKmbFYbapq%2BKir2w%40mail.gmail.com.


Re: [go-nuts] randomly go loading modules fail

2020-05-15 Thread Tyler Compton
I saw some discussion in a previous thread indicating that Gitlab is having
an incident. More details here:
https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7

On Fri, May 15, 2020 at 10:04 AM msherif4 via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi :
>
>  I have seen randomly go dependancies fail to load certain modules
> like the case below
>
> [0m [91mgo: modernc.org/mathutil@v1.0.0: git fetch -f origin 
> refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
> /go/pkg/mod/cache/vcs/fb72eb2422fda47ac75ca695d44b06b82f3df3c5308e271486fca5e320879130:
>  exit status 128:
>   fatal: unable to access 'https://gitlab.com/cznic/mathutil/': The 
> requested URL returned error: 502
>
>
> [0m [91mgo: modernc.org/xc@v1.0.0: git fetch -f origin 
> refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in 
> /go/pkg/mod/cache/vcs/29fc2f846f24ce3630fdd4abfc664927c4ad22f98a3589050facafa0991faada:
>  exit status 128:
>   fatal: unable to access 'https://gitlab.com/cznic/xc/': The requested 
> URL returned error: 502
> go: error loading module requirements
>
>
> again this happens randomly not consistent
>
>
> anyone run into the same and is there anyway to fix it ?
>
>
> 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/5e12cce1-dcee-4276-97af-daf4bec9e111%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/CAA%3DXfu3sfkRUkCnvw84vb-FXU%2BupRBDsEmcQzJnLuoWBNfd8-Q%40mail.gmail.com.


Re: [go-nuts] Re: What are finalizers missing?

2020-02-18 Thread Tyler Compton
Good point, I had forgotten about the 2 minute rule the GC has.

So it's not a matter of  the go runtime not knowing "which Go objects it
> can finalize in order to get that [a resource] back", its simply a matter
> of the variable pace of GC. In theory GC can happen as infrequently as
> every 2 minutes. So if you are ok with you non-Go resource lingering for
> that long, then use finalizers. In most cases that is not sufficient though.
>

I think you're touching on the point I'm trying to make. The variable pace
of the GC is okay for Go memory, because it can adjust that pace if
necessary to keep up with garbage production. The GC can't make pace
adjustments based on the consumption of any non-Go-memory resources, which
means we can only count on a maximum of 2 minutes between GC runs.

I could certainly see situations where there's no way the GC could make a
smart enough decision to fit an application's needs, however. For example,
if your program writes to a file that another program then uses, you would
want to make sure that the file is closed before that other program is spun
up. Even a 1 second GC delay might not work here.

On Sat, Feb 15, 2020 at 10:52 AM Jake Montgomery  wrote:

> On Friday, February 14, 2020 at 2:10:01 PM UTC-5, Tyler Compton wrote:
>>
>> The conventional wisdom I see in the Go community is to avoid using
>> finalizers to manage file descriptors, C memory, or any other non-Go memory
>> resource. The generally accepted rationale (at least to my understanding)
>> is that the garbage collector cannot be expected to run the finalizer
>> promptly, and it may never be run at all.
>>
>>
>
>> This is where I start speculating. I assume this is because the garbage
>> collector has no understanding of C memory, file descriptors, or any other
>> kind of resource. If we're running out of memory due to a malloc in C,
>> there's no way for the garbage collector to know which Go objects it can
>> finalize in order to get that memory back.
>>
>
> I don't think your analysis is correct. IIRC, the spec makes no guarantees
> about finalizers ever actually being run. But in practice they will all be
> found and run after the first garbage collection after the object becomes
> unreachable. (Assuming the app continues to run.) So it's not a matter of
> the go runtime not knowing "which Go objects it can finalize in order to
> get that [a resource] back", its simply a matter of the variable pace of
> GC. In theory GC can happen as infrequently as every 2 minutes. So if you
> are ok with you non-Go resource lingering for that long, then use
> finalizers. In most cases that is not sufficient though.
>
> One other, minor, consideration, is also that setting a finalizer will
> cause the object to escape to the heap.
>
> --
> 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/9d2fd31b-f283-4dec-bb38-8cc8cc844249%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/9d2fd31b-f283-4dec-bb38-8cc8cc844249%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/CAA%3DXfu1OF_tBMKXgJKCFU9U_SNvdiKTvg1c%2B9-4KFL7e5jo5bA%40mail.gmail.com.


[go-nuts] Re: What are finalizers missing?

2020-02-14 Thread Tyler Compton
I found a relevant blog post by David Crawshaw that touches on the topic of
a garbage collector that can be extended to understand resources other than
Go-managed memory: https://crawshaw.io/blog/tragedy-of-finalizers

On Fri, Feb 14, 2020 at 11:09 AM Tyler Compton  wrote:

> The conventional wisdom I see in the Go community is to avoid using
> finalizers to manage file descriptors, C memory, or any other non-Go memory
> resource. The generally accepted rationale (at least to my understanding)
> is that the garbage collector cannot be expected to run the finalizer
> promptly, and it may never be run at all.
>
> This is where I start speculating. I assume this is because the garbage
> collector has no understanding of C memory, file descriptors, or any other
> kind of resource. If we're running out of memory due to a malloc in C,
> there's no way for the garbage collector to know which Go objects it can
> finalize in order to get that memory back. However, as a thought
> experiment, if we were able to tell the garbage collector (say, through a
> function in the runtime package) that a certain Go object owns X number of
> file descriptors or X bytes of C memory, could the garbage collector be
> augmented to free these objects (and thus run their finalizers)
> intelligently? Would doing so allow us to use finalizers for these
> resources with confidence?
>
> I don't mean this to be a proposal or suggestion. I'm asking more as an
> opportunity to learn.
>

-- 
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/CAA%3DXfu2RULyyHRn35t7YUJ%3DtWcRYmEYUWD%2Bmy8R_aqnD1%2B7OiQ%40mail.gmail.com.


Re: [go-nuts] What are finalizers missing?

2020-02-14 Thread Tyler Compton
Thanks for the pointer! I took a look at PhantomReferences and Cleaners,
and I see how they could be a more robust way to free resources for an
object. However, I don't see a mechanism by which they can express to the
garbage collector how much "pressure" they exert on a finite resource (file
descriptors, memory not managed by the Java GC, etc). I don't know very
much about the Java GC, but in a scenario where we have a few Java objects
with a low amount of memory usage but with a large number of (for example)
file descriptors, the Java GC might just decide not to run because it has
no knowledge of the fact that running would help free up file descriptors.

In other words, I see how PhantomReferences and Cleaners are less brittle
than runtime.SetFinalizer, but not how they're more capable of managing
resources that the GC is not already aware of.

On Fri, Feb 14, 2020 at 11:17 AM Robert Engels 
wrote:

>
> I suggest you look at PhantomReference in Java, and the Cleaner/Disposer
> classes/patterns for how this would work. Go doesn't have
> PhantomReferences, so it's moot at this time.
>
> -Original Message-
> From: Tyler Compton
> Sent: Feb 14, 2020 1:09 PM
> To: golang-nuts
> Subject: [go-nuts] What are finalizers missing?
>
> The conventional wisdom I see in the Go community is to avoid using
> finalizers to manage file descriptors, C memory, or any other non-Go memory
> resource. The generally accepted rationale (at least to my understanding)
> is that the garbage collector cannot be expected to run the finalizer
> promptly, and it may never be run at all.
>
> This is where I start speculating. I assume this is because the garbage
> collector has no understanding of C memory, file descriptors, or any other
> kind of resource. If we're running out of memory due to a malloc in C,
> there's no way for the garbage collector to know which Go objects it can
> finalize in order to get that memory back. However, as a thought
> experiment, if we were able to tell the garbage collector (say, through a
> function in the runtime package) that a certain Go object owns X number of
> file descriptors or X bytes of C memory, could the garbage collector be
> augmented to free these objects (and thus run their finalizers)
> intelligently? Would doing so allow us to use finalizers for these
> resources with confidence?
>
> I don't mean this to be a proposal or suggestion. I'm asking more as an
> opportunity to learn.
>
> --
> 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/CAA%3DXfu3xrghcLhrj3La1niVnHs07DdCUUDfWjpVTyTUkhMwTjA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3xrghcLhrj3La1niVnHs07DdCUUDfWjpVTyTUkhMwTjA%40mail.gmail.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/CAA%3DXfu0%2B5zLVZOW6RrMLcBEKJ0KEVRsdBvDKEP96mavD0hHxUQ%40mail.gmail.com.


[go-nuts] What are finalizers missing?

2020-02-14 Thread Tyler Compton
The conventional wisdom I see in the Go community is to avoid using
finalizers to manage file descriptors, C memory, or any other non-Go memory
resource. The generally accepted rationale (at least to my understanding)
is that the garbage collector cannot be expected to run the finalizer
promptly, and it may never be run at all.

This is where I start speculating. I assume this is because the garbage
collector has no understanding of C memory, file descriptors, or any other
kind of resource. If we're running out of memory due to a malloc in C,
there's no way for the garbage collector to know which Go objects it can
finalize in order to get that memory back. However, as a thought
experiment, if we were able to tell the garbage collector (say, through a
function in the runtime package) that a certain Go object owns X number of
file descriptors or X bytes of C memory, could the garbage collector be
augmented to free these objects (and thus run their finalizers)
intelligently? Would doing so allow us to use finalizers for these
resources with confidence?

I don't mean this to be a proposal or suggestion. I'm asking more as an
opportunity to learn.

-- 
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/CAA%3DXfu3xrghcLhrj3La1niVnHs07DdCUUDfWjpVTyTUkhMwTjA%40mail.gmail.com.


Re: [go-nuts] Why Discord is switching from Go to Rust

2020-02-07 Thread Tyler Compton
It would have been nice to see performance measurements from a more recent
Go version. That said, it makes sense to me that Rust would be a better
choice for this kind of application, where the main performance bottleneck
is the sheer number of objects in memory. A language where you get to
express more about the life-cycle of these objects should perform better. I
say this as someone that knows very little about Rust, so I'm probably
greatly oversimplifying.

On Fri, Feb 7, 2020 at 4:25 AM Everton Marques 
wrote:

> I think Go is way better than Rust, but it is amusing to see why people
> pick one over another.
>
> "Remarkably, we had only put very basic thought into optimization as the
> Rust version was written. Even with just basic optimization, Rust was able
> to outperform the hyper hand-tuned Go version. This is a huge testament to
> how easy it is to write efficient programs with Rust compared to the deep
> dive we had to do with Go."
>
>
> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f
>
> --
> 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/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%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/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com.


Re: [go-nuts] Re: go1.12.16 not tagged on release-branch.go1.12?

2020-01-29 Thread Tyler Compton
I think it's very reasonable to ask a simple Git workflow question on
golang-nuts without having to provide reproduction steps.

Yes, I posted the error in reproducible form. The first step in fixing a
> bug. The Go team can confirm the bug and verify that their fix works. No
> guesswork required.


I think you're unintentionally coming off as condescending.

On Wed, Jan 29, 2020 at 5:31 AM peterGo  wrote:

> Steve,
>
> "I don't see"
>
> Please provide reproducible errors. For example,
>
> [security] Go 1.13.7 and Go 1.12.16 are released
> https://groups.google.com/forum/#!topic/golang-nuts/4uVpv5Zfxvo
>
> ~$ git clone https://github.com/golang/go --depth 1 -b
> release-branch.go1.12 go1.12
> Cloning into 'go1.12'...
> remote: Enumerating objects: 9305, done.
> remote: Counting objects: 100% (9305/9305), done.
> remote: Compressing objects: 100% (7682/7682), done.
> remote: Total 9305 (delta 1465), reused 4643 (delta 1134), pack-reused 0
> Receiving objects: 100% (9305/9305), 21.22 MiB | 11.94 MiB/s, done.
> Resolving deltas: 100% (1465/1465), done.
> ~$ cd go1.12/src
> ~/go1.12/src$ ./make.bash
> Building Go cmd/dist using /home/peter/go1.4.
> Building Go toolchain1 using /home/peter/go1.4.
> Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
> Building Go toolchain2 using go_bootstrap and Go toolchain1.
> Building Go toolchain3 using go_bootstrap and Go toolchain2.
> Building packages and commands for linux/amd64.
> ---
> Installed Go for linux/amd64 in /home/peter/go1.12
> Installed commands in /home/peter/go1.12/bin
> ~/go1.12/src$ cd ../bin
> ~/go1.12/bin$ ./go version
> go version go1.12.15 linux/amd64
> ~/go1.12/bin$
>
> Peter
>
> On Wednesday, January 29, 2020 at 6:30:23 AM UTC-5, Steve Mynott wrote:
>>
>> I don't see go1.12.16 tagged on release-branch.go1.12?
>>
>> Is this expected?
>>
>> --
>> Steve Mynott 
>> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5
>>
> --
> 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/3522d571-43da-48c3-8158-286ce7c4b092%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/CAA%3DXfu0wkWH2tc5_97FQoHHu%3DZC4E0CATM5u%2BnF0VQv3fxeEwA%40mail.gmail.com.


Re: [go-nuts] Golang and EOL of Windows 7 (Windows Server 2008)

2019-11-18 Thread Tyler Compton
As a data point, Go stopped supporting Windows XP in Go 1.10. That's 4
years after Microsoft officially ended support for the operating system. I
don't think that's a hard rule, and it will probably depend on what version
Go's main Windows contributors use.

Relevant issue: https://golang.org/issues/23380

On Mon, Nov 18, 2019 at 10:12 AM 'Pier-Hugues Pellerin' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
> Hello everyone,
>
> I've been trying to find information about how the Go team deals with EOL
> of a specific platform.
> I am working on products that currently support Windows 7 and were users
> will not move quickly out of the
> platform.
>
> Since the EOL of Windows 7 (and Windows Server 2008) is scheduled for
> January 14, 2020,  I would like to know if there is any
> plan to remove that platform and if so is there a target version for that
> removal?
>
> I've looked at the Github tracker, but I haven't found anything related to
> that.
>
> Thanks
>
> PH
>
>
> --
> 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/c10234c5-943b-4061-85c9-a5cf06202372%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/CAA%3DXfu2a1fY8tsjqPN7rPfRpv_Zh3q2mKqJFQKQig9uuPYma9A%40mail.gmail.com.


[go-nuts] Re: [golang-dev] go.dev is live!

2019-11-13 Thread Tyler Compton
Thanks for posting! I'm really impressed the website, and with the package
view especially. I foresee myself using this instead of godoc.org from now
on.

I'm curious to hear more about the team's future plans for golang.org. Do
you have any plans to migrate or mirror content like the blog or the
download links over time? I could see some minor confusion popping up
regarding which website to go to for which task, though I see this has been
partially addressed by adding links to many of golang.org's resources on
go.dev, which is thoughtful.

On Wed, Nov 13, 2019, 09:15 'Julie Qiu' via golang-dev <
golang-...@googlegroups.com> wrote:

> Hey Gophers,
>
> We are excited to share that go.dev, a new hub for Go developers, is now
> live!
>
> At go.dev, you will find information on how to get started with the
> language, featured use cases, and other resources. It is a companion site
> to golang.org. You can read about it on the latest Go blog post
> .
>
> You will also find a new place to discover Go packages and modules,
> pkg.go.dev, by clicking on Explore in the header or footer.
>
> Pkg.go.dev  serves Go documentation like godoc.org,
> but it also understands modules and has information about previous versions
> of a package (such as all releases of the Go standard library
> !). It also detects and displays
> licenses and has a better search algorithm.
>
> You can follow Go issue 33654  for future
> developments on pkg.go.dev.
>
> We are just starting to build out go.dev, so some bugs are to be
> expected. We want to work with all of you to make this site better for Go
> developers, so please share your feedback with us and file issues if you
> spot them! You can do that by clicking "Share Feedback" or "Report an
> Issue" at the footer of every page, or by emailing
> go-discovery-feedb...@google.com. See go.dev/about for more information
> about the site.
>
> We hope you enjoy the new site and look forward to hearing your feedback!
>
> Warmly ☀️,
>
> Julie for the Go team
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/CAGJ2NqEcskx_492HFpV%3DUavMLgXoYmXaZ1ivigqnjfc-9U8wFA%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/CAA%3DXfu0AnuaU74-7dAriVk2JhUV3_850xGLLDfjnBodrq_-8QQ%40mail.gmail.com.


Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

2019-11-06 Thread Tyler Compton
That's a good point. Also, now that I think of it, with the help of a
profiler it should be straightforward to identify places where iterating
over a slice is a problem regardless of how the iteration is expressed. I'm
convinced!

On Tue, Nov 5, 2019 at 4:05 PM Robert Engels  wrote:

> I think that’s splitting hairs a bit. Even if you see the loop you don’t
> know the cost unless you know the size of a slice. For instance, a lookup
> in a small slice is actually cheaper than a small map - in memory and
> speed. So you need to know more than “it’s a slice” to make a judgement.
>
> On Nov 5, 2019, at 5:58 PM, Tyler Compton  wrote:
>
> 
> I agree with you that an original writer of the code should be expected to
> know that a theoretical "contains" or "in" expression has O(n) properties.
> However, I've always thought of this from the perspective of someone
> looking at the code later and trying to identify performance issues. It's
> easy to identify a potentially very costly iteration through a slice if
> it's more verbose and always expressed the same way.
>
> On Tue, Nov 5, 2019 at 2:44 PM Robert Engels 
> wrote:
>
>> Is it though?
>>
>> You would have the same problem if you thought the size of mySlice was
>> always small, and it wasn't - range could be quite expensive (or not) - and
>> if that was not valid workable you should be using something other than a
>> slice.
>>
>> You need understanding of the types and cost of operations in any
>> language, and the naming (or something else) should make the types easily
>> recognizable (and understandable).
>>
>>
>> -Original Message-
>> From: Tyler Compton
>> Sent: Nov 5, 2019 3:57 PM
>> To: toddsu...@icloud.com
>> Cc: golang-nuts
>> Subject: Re: [go-nuts] Why doesn't Go include a contains method for
>> things like slices?
>>
>> Ian's answer addresses your question about the absence of a
>> slice.Contains method, but there have been discussions in the past about
>> adding such a feature to the language itself as well. You brought up the
>> idea of a builtin "contains" function, and I've seen others suggest adding
>> something like Python's "in" operator as well. To most of these proposals,
>> the answer has been "no" because of concerns about hiding a potentially
>> very expensive operation behind a builtin or operator. There's no doubt
>> that:
>>
>> return myObj in mySlice
>>
>> ... is easier to miss than:
>>
>> for _, obj := range mySlice {
>> if obj == myObj {
>> return true
>> }
>> }
>> return false
>>
>> On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Sorry if this question reveals my newness to Go. I tried searching the
>>> mailing list but I couldn't find anything in a quick search. It seems like
>>> many languages include the ability to check if an array, or slice contain a
>>> particular value. I understand that you could do this easily with a for
>>> loop or alternatively use a map instead. However, is there a reason why Go
>>> doesn't just have slice.Contains(interface{}) or maybe a builtin
>>> contains(mySlice, interface{}) ?
>>>
>>> I assume one reason might be because slices could potentially be really
>>> large? Or maybe the community feels that a simple for loop is so easy that
>>> it is not necessary? I would love to understand this more.
>>>
>>> Thank You!
>>> -Todd
>>>
>>> --
>>> 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/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%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/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.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/CAA%3DXfu3LVUjcz7jg%2BmUhGvbmhHL%2B6ycgh7zNouRx6_JwN-eDoQ%40mail.gmail.com.


Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

2019-11-05 Thread Tyler Compton
I should mention that I don't 100% buy this argument and I would still like
to see a "slices.Contains" function in the future if/when generics are
added. I'm trying (perhaps poorly) to explain what I've seen as the most
common argument against adding such a feature.

On Tue, Nov 5, 2019 at 3:58 PM Tyler Compton  wrote:

> I agree with you that an original writer of the code should be expected to
> know that a theoretical "contains" or "in" expression has O(n) properties.
> However, I've always thought of this from the perspective of someone
> looking at the code later and trying to identify performance issues. It's
> easy to identify a potentially very costly iteration through a slice if
> it's more verbose and always expressed the same way.
>
> On Tue, Nov 5, 2019 at 2:44 PM Robert Engels 
> wrote:
>
>> Is it though?
>>
>> You would have the same problem if you thought the size of mySlice was
>> always small, and it wasn't - range could be quite expensive (or not) - and
>> if that was not valid workable you should be using something other than a
>> slice.
>>
>> You need understanding of the types and cost of operations in any
>> language, and the naming (or something else) should make the types easily
>> recognizable (and understandable).
>>
>>
>> -Original Message-
>> From: Tyler Compton
>> Sent: Nov 5, 2019 3:57 PM
>> To: toddsu...@icloud.com
>> Cc: golang-nuts
>> Subject: Re: [go-nuts] Why doesn't Go include a contains method for
>> things like slices?
>>
>> Ian's answer addresses your question about the absence of a
>> slice.Contains method, but there have been discussions in the past about
>> adding such a feature to the language itself as well. You brought up the
>> idea of a builtin "contains" function, and I've seen others suggest adding
>> something like Python's "in" operator as well. To most of these proposals,
>> the answer has been "no" because of concerns about hiding a potentially
>> very expensive operation behind a builtin or operator. There's no doubt
>> that:
>>
>> return myObj in mySlice
>>
>> ... is easier to miss than:
>>
>> for _, obj := range mySlice {
>> if obj == myObj {
>> return true
>> }
>> }
>> return false
>>
>> On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Sorry if this question reveals my newness to Go. I tried searching the
>>> mailing list but I couldn't find anything in a quick search. It seems like
>>> many languages include the ability to check if an array, or slice contain a
>>> particular value. I understand that you could do this easily with a for
>>> loop or alternatively use a map instead. However, is there a reason why Go
>>> doesn't just have slice.Contains(interface{}) or maybe a builtin
>>> contains(mySlice, interface{}) ?
>>>
>>> I assume one reason might be because slices could potentially be really
>>> large? Or maybe the community feels that a simple for loop is so easy that
>>> it is not necessary? I would love to understand this more.
>>>
>>> Thank You!
>>> -Todd
>>>
>>> --
>>> 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/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%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/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.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/CAA%3DXfu0nutbzRuStD7bfWFXu5v0mGJcOpoXyc4ZLK7bW67vtaw%40mail.gmail.com.


Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

2019-11-05 Thread Tyler Compton
I agree with you that an original writer of the code should be expected to
know that a theoretical "contains" or "in" expression has O(n) properties.
However, I've always thought of this from the perspective of someone
looking at the code later and trying to identify performance issues. It's
easy to identify a potentially very costly iteration through a slice if
it's more verbose and always expressed the same way.

On Tue, Nov 5, 2019 at 2:44 PM Robert Engels  wrote:

> Is it though?
>
> You would have the same problem if you thought the size of mySlice was
> always small, and it wasn't - range could be quite expensive (or not) - and
> if that was not valid workable you should be using something other than a
> slice.
>
> You need understanding of the types and cost of operations in any
> language, and the naming (or something else) should make the types easily
> recognizable (and understandable).
>
>
> -Original Message-
> From: Tyler Compton
> Sent: Nov 5, 2019 3:57 PM
> To: toddsu...@icloud.com
> Cc: golang-nuts
> Subject: Re: [go-nuts] Why doesn't Go include a contains method for things
> like slices?
>
> Ian's answer addresses your question about the absence of a slice.Contains
> method, but there have been discussions in the past about adding such a
> feature to the language itself as well. You brought up the idea of a
> builtin "contains" function, and I've seen others suggest adding something
> like Python's "in" operator as well. To most of these proposals, the answer
> has been "no" because of concerns about hiding a potentially very expensive
> operation behind a builtin or operator. There's no doubt that:
>
> return myObj in mySlice
>
> ... is easier to miss than:
>
> for _, obj := range mySlice {
> if obj == myObj {
> return true
> }
> }
> return false
>
> On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Sorry if this question reveals my newness to Go. I tried searching the
>> mailing list but I couldn't find anything in a quick search. It seems like
>> many languages include the ability to check if an array, or slice contain a
>> particular value. I understand that you could do this easily with a for
>> loop or alternatively use a map instead. However, is there a reason why Go
>> doesn't just have slice.Contains(interface{}) or maybe a builtin
>> contains(mySlice, interface{}) ?
>>
>> I assume one reason might be because slices could potentially be really
>> large? Or maybe the community feels that a simple for loop is so easy that
>> it is not necessary? I would love to understand this more.
>>
>> Thank You!
>> -Todd
>>
>> --
>> 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/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%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/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.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/CAA%3DXfu1icLW8yRRX6%2BW6XVmX8k6SpkUSKNSPnejtEMdgyidu4Q%40mail.gmail.com.


Re: [go-nuts] Why doesn't Go include a contains method for things like slices?

2019-11-05 Thread Tyler Compton
Ian's answer addresses your question about the absence of a slice.Contains
method, but there have been discussions in the past about adding such a
feature to the language itself as well. You brought up the idea of a
builtin "contains" function, and I've seen others suggest adding something
like Python's "in" operator as well. To most of these proposals, the answer
has been "no" because of concerns about hiding a potentially very expensive
operation behind a builtin or operator. There's no doubt that:

return myObj in mySlice

... is easier to miss than:

for _, obj := range mySlice {
if obj == myObj {
return true
}
}
return false

On Tue, Nov 5, 2019 at 12:30 PM toddsurfs via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Sorry if this question reveals my newness to Go. I tried searching the
> mailing list but I couldn't find anything in a quick search. It seems like
> many languages include the ability to check if an array, or slice contain a
> particular value. I understand that you could do this easily with a for
> loop or alternatively use a map instead. However, is there a reason why Go
> doesn't just have slice.Contains(interface{}) or maybe a builtin
> contains(mySlice, interface{}) ?
>
> I assume one reason might be because slices could potentially be really
> large? Or maybe the community feels that a simple for loop is so easy that
> it is not necessary? I would love to understand this more.
>
> Thank You!
> -Todd
>
> --
> 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/7d4c52e3-8c0f-4ba6-ae24-67ddb4a07ede%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/CAA%3DXfu33vuhzU1krGJKUZNaj6fNOhYQQY4%2BBfNtsdq0o7Q116w%40mail.gmail.com.


Re: [go-nuts] using Go as a configuration file format

2019-09-24 Thread Tyler Compton
I do think that turing complete configuration have their place in very
limited circumstances. For example, I use a window manager called Awesome
WM that is configured with Lua, and that allows me to implement my own
features into the WM while configuring it. The significant disadvantage
here is that Awesome WM exposes a very large API surface to the
configuration file, making it very likely that your configuration will
break with a new release, and writing an automatic migration would be
significantly more difficult than if it were a configuration file.

It makes it impossible to implement a parser and evaluator for the format
> in a different language. Which should always be possible for a config file
> format.
>

This problem can be partially addressed by using a language like Lua that
has a very small C interpreter library and can be called from a variety of
languages, but I appreciate your point.


>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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/CABx2%3DD8Qi8JFA4WSCU7TLuXmgjx-WcAzJcuDdV08XSwz%2Bicziw%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/CAA%3DXfu3%3DQgaWDXCc9MWxOaRkYYwYg7_Ka%2BpoNLYs8CjgK%2B0QMA%40mail.gmail.com.


Re: [go-nuts] How to do a forward compatibility support for go 1.13?

2019-09-06 Thread Tyler Compton
I think that in general you will have to only use features available to Go
1.11, meaning, of course, that the new methods in the errors package would
be off limits. In the mean time you could use golang.org/x/xerrors, which
is a superset of the new errors package and I believe will work with 1.11.

On Fri, Sep 6, 2019, 7:50 AM changkun  wrote:

> I have upgraded my code to Go 1.13 with newly introduced errors APIs.
>
> However, I am not able to upgrade the production environment Go version
> which is Go 1.11, which means I have to run Go 1.13 code on a Go 1.11
> environment.
>
> What are the way to make my builds both happy on local and production
> environment with a single code base?
>
> --
> 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/0a915d38-39f4-4083-b730-75320a4eecc6%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/CAA%3DXfu1cXxzt7B4L%2B7sHw%3DxT-%2BA5J44n1PdtszQ%3DxTAoJOwU_g%40mail.gmail.com.


Re: [go-nuts] [ANN] sqlc: Generate type-safe Go from SQL

2019-09-03 Thread Tyler Compton
This is very cool! It's an interesting compromise between using a fully
featured ORM and interacting with SQL queries directly, and may be a good
sweet spot.

Have you considered supporting documentation in generated code? Maybe by
allowing for syntax like this for queries:

-- name: ListAuthors :many
--
-- ListAuthors retrieves all authors from the database blah blah.
SELECT * FROM authors
ORDER BY name;

... that would generate code like this:

// ListAuthors retrieves all authors from the database blah blah.
func (q *Queries) ListAuthors(ctx context.Context) ([]Author, error) {
...
}

I'm not too familiar with Postgres, but in MySQL you can create tables with
comments. It looks like there's a similar feature in Postgres.

CREATE TABLE authors (
id int,
name VARCHAR(255) COMMENT "The name of the author who wrote the book",
bio VARCHAR(512) COMMENT "A short description of the author"
) COMMENT "Author is the author of a piece of literature.";

It might be nice if those comments propagated to the struct definition
automatically.

// Author is the author of a piece of literature.
type Author struct {
ID   int64
// The name of the author who wrote the book
Name string
// A short description of the author
Bio  sql.NullString
}

On Tue, Sep 3, 2019 at 7:43 AM  wrote:

> Hey folks,
>
> I'd like to introduce sqlc[0], a tool that compiles SQL queries into
> type-safe, idiomatic Go. It also catches common errors in SQL such as
> mistyped column names and incorrect parameter numbering.
>
> If this sounds like something that would be useful to you, take a read
> through the Getting Started[1] guide.
>
> Cheers,
> Kyle
>
> [0] https://github.com/kyleconroy/sqlc
> [1]
> https://github.com/kyleconroy/sqlc/blob/master/README.md#getting-started
>
> --
> 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/399e7595-1f79-4fc5-a6bd-498b312168d5%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/CAA%3DXfu1-ex8soB6yK76SqMJohSgE%2B%2BhiR4cvgB28mHiEVVYe%2BA%40mail.gmail.com.


Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

2019-06-29 Thread Tyler Compton
>
> I wish we had a Zen of Go and followed it.
>

You may be interested in this: https://go-proverbs.github.io/


>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em sáb, 29 de jun de 2019 às 20:18, Denis Cheremisov <
> denis.cheremi...@gmail.com> escreveu:
>
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>
>> --
>> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2B%3DiygtUkrJLW1jP9f-Q-YtgkjJnSGVg6rJYW%3DD8jvrjYZwWZw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0wJYeCxhSTxKotOs3XnGLx5LAWPdEFr%2BR5m2C-wd9yjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

2019-06-29 Thread Tyler Compton
Sorry, forgot to CC on my last email. Here it is again:

And you must understand the specific: you are solving relatively hard
> problems developing language called Go with low mistake cost and we are
> solving simple problems with a DSL called Go but our mistake cost is much
> higher than yours.
>

Sorry, I'm not sure I understand. Who is the "you" and "we" in these
circumstances? I should be clear, I'm not a Go core team member and I had
nothing to do with the creation of the original "try" proposal. I've just
been involved in the proposal and anti-proposal discussion and noticed a
shift in tone.

I thought you are trying to be as practical as possible making a language
> with such a retarded yet somehow usable type system in XXI. But this recent
> proposal raises some suspicions...
>

What is XXI? Are you referring to Go's type system?

On Sat, Jun 29, 2019 at 12:18 PM Denis Cheremisov <
denis.cheremi...@gmail.com> wrote:

> And prepare for wider audience in shitty “try” proposal after 1 July.
>
> --
> 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/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu031bDbJheZ5-JUbsea1%2BYAn68dfO5ve8pn4T7%3DRFxqRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] The "leave "if err != nil" alone?" anti-proposal

2019-06-28 Thread Tyler Compton
If anyone hasn't seen it, an issue with the "proposal" tag was created
earlier on the Go issue tracker titled "Proposal: leave "if err != nil"
alone?" (here ). This issue seems to have
resonated with a lot of people, which may be an important data point when
considering the try proposal , but I was
surprised to see how poorly the discussion has gone. There are quite a few
"me too" comments, a few image-only posts, some less than stellar personal
conduct, and overall not a lot of nuanced discussion. I feel that perhaps
these kinds of anti-proposals should be discouraged because they're
inherently reactionary, which seems to get the discussion off on the wrong
foot.

That said, this anti-proposal attracted a whole new group of Go users that
I don't remember from the original try proposal discussion, which was
mostly dominated by ten or twenty participants. The discussion was better,
but the number of active users was much smaller. I wonder if there's a way
to better engage a larger portion of the Go user base while still
encouraging healthy, technical discussion.

-- 
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/CAA%3DXfu3iym9EM_SKtFvyHNgusVF2yL3p1O4dgCs7_VPUnRzGJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Go GTK vs QT for Linux

2019-06-18 Thread Tyler Compton
Just noticed that I mentioned the wrong package. The runtime package for
GTK is libgtk-3-0.

On Mon, Jun 17, 2019 at 9:48 AM Tyler Compton  wrote:

> I haven't personally used this library, but I'd think you'd only
> need libgtk-3-dev and libappindicator3-dev at compile-time. You should be
> able to get away with the smaller runtime packages libgtk-3-dev
> and libappindicator3-1 once your application is built.
>
> On Mon, Jun 17, 2019 at 6:56 AM Subramanian Sridharan <
> clawsonfir...@gmail.com> wrote:
>
>> Hi guys
>>
>> I've been fiddling around this <https://github.com/getlantern/systray> 
>> package
>> which uses GTK bindings in Go to achieve systray functionality.
>> But it depends on *libgtk-3-dev *and* libappindicator3-dev *which amount
>> to around 300 MB.
>>
>> Have you guys come across any other package that implements GTK or QT
>> binding in Go?
>>
>> How do GTK and QT weight against each other with respect to Go?
>>
>> --
>> 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/c9d629e6-4e09-4c1a-ac69-906cd259f2af%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/c9d629e6-4e09-4c1a-ac69-906cd259f2af%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0__xK-J5ztz5GcLCq7sCtZAqf29mWtuzP38648RiC3iA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Go GTK vs QT for Linux

2019-06-17 Thread Tyler Compton
I haven't personally used this library, but I'd think you'd only
need libgtk-3-dev and libappindicator3-dev at compile-time. You should be
able to get away with the smaller runtime packages libgtk-3-dev
and libappindicator3-1 once your application is built.

On Mon, Jun 17, 2019 at 6:56 AM Subramanian Sridharan <
clawsonfir...@gmail.com> wrote:

> Hi guys
>
> I've been fiddling around this  package
> which uses GTK bindings in Go to achieve systray functionality.
> But it depends on *libgtk-3-dev *and* libappindicator3-dev *which amount
> to around 300 MB.
>
> Have you guys come across any other package that implements GTK or QT
> binding in Go?
>
> How do GTK and QT weight against each other with respect to Go?
>
> --
> 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/c9d629e6-4e09-4c1a-ac69-906cd259f2af%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0PAiuSnoWysjmmgBV5_P3PK2HS1XdKJaXDiA3ufhFTtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Bugs on switch

2019-06-17 Thread Tyler Compton
Andrew is right, but I'll also add that if you really do want fallthrough
semantics, you can use the "fallthrough" keyword:
https://play.golang.com/p/x2gBb905Hj0

Go opts to make the somewhat uncommon case of fallthrough explicit, and the
more common "break" case implicit. A bit surprising for new Go programmers
but it does allow for most switch statements to be quite a bit less verbose.

On Mon, Jun 17, 2019 at 7:35 AM Andrew Klager 
wrote:

> I'm going to guess, based on the "break" statement in the final case, that
> you expect each of the case statements without a break to fall through to
> the nest case. Go does not work like that. By default, each case, whether
> there's any action taken or not, breaks. Take a look at this to accomplish
> what you're probably looking for: https://play.golang.org/p/0aXXjoshOk9
>
> On Mon, Jun 17, 2019 at 9:26 AM  wrote:
>
>> i write example code standard switch statement
>> https://play.golang.org/p/kOplHDBk8Df
>>
>> program exited without print something.
>>
>> --
>> 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/88c11740-e4a2-43af-8d4f-45c986cc55df%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CABn4WMUt%2BD30_OuKORFnMJL6okHYU5TVHKpX-rEqyyJ_Y15DKw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu3sj63znKC8YSo6FTnj3-UJPRoOuGqxvGUemCLo4pNjVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] cgo libnice binding will stuck

2019-05-22 Thread Tyler Compton
Beyond just mailing list etiquette, you'll probably get better responses if
you provide your code in plain text. I think that some of the more
responsive people in golang-nuts use text-only email viewers, though that's
only a guess!

I took the liberty of transcribing this one, free of charge :)

func (a *Agent) GatherCandidates() error {
a.mtx.Lock()
defer a.mtx.Unlock()
fmt.Println("GatherCandidates1")
rv := int(C.nice_agent_gather_candidates(a.agent, C.guint(a.stream)))
if rv == 0 {
return errors.New("failed to gather candidates")
}
fmt.Println("GatherCandidates2")
return nil
}

On Wed, May 22, 2019 at 3:09 AM xiang liu  wrote:

> Sorry about this.
>
> 在 2019年5月22日星期三 UTC+8下午4:43:27,Jan Mercl写道:
>>
>> On Wed, May 22, 2019 at 10:05 AM xiang liu  wrote:
>>
>> Please use only plain text for source code in emails. Where available,
>> a link to play.golang.org is also good. 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/1379f6a2-e700-43ed-8cf6-c633ea567d1b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2_63yEwDu1-4aWi0WBUW82xL9JqMwf3726DGkwwHQH0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Http Handler to produce static content

2019-05-20 Thread Tyler Compton
> Sorry I don't quite understand -- my go application IS my webserver.
>

This is a topic that has confused me in the past. In the simple case where
you build a Go executable and get requests from it directly, your Go
application *is* your web server. However, it's common in industry to put a
system like nginx in front of your Go executable that takes care of serving
static content like images, JavaScript, CSS, and so on to the user without
consulting your Go application at all. Then, when this web server gets a
request on and endpoint that it doesn't know how to serve, like an API
call, it will forward that request to your Go application.

With a setup like this, you're able to concentrate on writing business
logic in Go and configure caching and static resource management elsewhere.
In these cases, the application in front of your Go application is the "web
server" because it is in charge of directly serving resources to the
client. Your Go application might be called the "web application" because
it is in charge of doing application-specific tasks. It isn't strictly
necessary to adopt this format just to cache static resources, but if your
needs become more complicated in the future it might be something worth
considering :)


> Are you saying Go net/http is not capable of doing what I'm asking?
>
> On Sun, May 19, 2019 at 9:59 AM satyendra singh
>  wrote:
> >
> > Hi Tong,
> > You can use a webserver between browser and your go application which
> will take care of header modification for browser caching.
> >
> > Thanks and regards,
> > Satyendra
> >
> > On Sun, 19 May, 2019, 7:26 PM Tong Sun,  wrote:
> >>
> >> Hi,
> >>
> >> How to have http.Handle / http.HandleFunc to produce static content
> that browser will use their caches without downloading every time?
> >>
> >> For a simplest http.HandleFunc, like the following,
> >>
> >> func sayHello(w http.ResponseWriter, r *http.Request) {
> >>message := "Hello "
> >>
> >>w.Write([]byte(message))
> >> }
> >>
> >>
> >>
> >> Thet HTTP Header it produce is:
> >>
> >> HTTP/1.1 200 OK
> >> Date: Sun, 19 May 2019 13:46:32 GMT
> >> Content-Length: 6
> >> Content-Type: text/plain; charset=utf-8
> >>
> >>
> >> I.e., the "Date:" part is changing all the time, even if I've added a
> "last-modified" Header field.
> >>
> >> What's the solution? Thx
>
> --
> 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/CAMmz1OeBW5rp4RcfYtC%3Dk%3DpeX%3DdizF5G9Gv0Y1dgm5%2BG3%3DZBYA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2mC%2BvRQgWoMN-Sx-9AvrobDBobWug4etbQsk2rxC8MNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-nuts] Re: Random panic in production with Sprintf

2019-05-02 Thread Tyler Compton
I took a quick look and yes, it uses unsafe to convert between byte slices
and strings. I don't know enough to say that it's the problem but here's an
example:

https://github.com/valyala/fasthttp/blob/645361952477dfc16938fb2993065130ed7c02b9/bytesconv.go#L380

On Thu, May 2, 2019 at 5:16 PM Burak Serdar  wrote:

> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ  wrote:
> >
> > No use of C via CGO at all.
> >
> > Afaik, there isn't any unsafe use of the string, we are basically
> reading it from a get parameter (fasthttp server) on an http request and
> then adding it into this structure, most of the times is just a 5 char
> string. Out of several millions requests, this panic happens.
>
> Does this "fasthttp" have any unsafe pointers?
>
>
> >
> > I failed to find any kind of race using go race detector, I'm currently
> doing some more debugging, hopefuly I should have more info/tests soon.
> >
> > El jueves, 2 de mayo de 2019, 20:44:33 (UTC-3), Burak Serdar escribió:
> >>
> >> On Thu, May 2, 2019 at 3:56 PM Ian Lance Taylor 
> wrote:
> >> >
> >> > On Thu, May 2, 2019 at 2:50 PM Anthony Martin 
> wrote:
> >> > >
> >> > > What version of Go are you using?
> >> > >
> >> > > XXX ZZZ  once said:
> >> > > > fmt.(*pp).fmtString(0xc023c17740, 0x0, 0x5, 0xc00076)
> >> > > > /usr/local/go/src/fmt/print.go:448 +0x132
> >> > > > fmt.(*pp).printArg(0xc023c17740, 0x9978e0, 0xc016a68a30, 0x76)
> >> > > > /usr/local/go/src/fmt/print.go:684 +0x880
> >> > > > fmt.(*pp).doPrintf(0xc023c17740, 0xa6e22f, 0x5, 0xc048c27818,
> 0x1, 0x1)
> >> > > > /usr/local/go/src/fmt/print.go:1112 +0x3ff
> >> > > > fmt.Sprintf(0xa6e22f, 0x5, 0xc048c27818, 0x1, 0x1, 0x80, 0xa36200)
> >> > > > /usr/local/go/src/fmt/print.go:214 +0x66
> >> > >
> >> > > This shows signs of memory corruption. The last argument passed to
> >> > > fmtString (0xc00076) should be the same as the last argument
> >> > > passed to printArg (0x76 or 'v') but it has some high bits set.
> Also,
> >> > > the pointer to the format string data changes from 0xa6e22f (which
> is
> >> > > probably in the .rodata section of the binary) to 0x0.
> >> > >
> >> > > Something is amiss.
> >> >
> >> > The change from 0x76 to 0xc00076 does not necessarily indicate a
> >> > problem.  The stack backtrace does not know the types.  The value here
> >> > is a rune, which is 32 bits.  The compiler will only set the low order
> >> > 32 bits on the stack, leaving the high order 32 bits unset.  So the
> >> > 0xc0 could just be garbage left on the stack.
> >> >
> >> > I don't *think* the format string is changing.  I think the 0 is from
> >> > the string being printed, not the format string.  They both happen to
> >> > be length 5.
> >>
> >> There's something that doesn't make sense here. The 0 is from the
> >> string being printed, it is not the format string. But how can that
> >> be?
> >>
> >> Even if there is a race, the string cannot have a 0 for the slice, can
> >> it? So the other option is when Sprintf is called, the string being
> >> printed is already corrupt. Can there be an overflow somewhere that is
> >> somehow undetected? Any unsafe use in the program?
> >>
> >>
> >> >
> >> > 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 golan...@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.
>
> --
> 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.


Re: [go-nuts] Re: Is it possible to simplify this snippet?

2019-05-01 Thread Tyler Compton
On Wed, May 1, 2019 at 7:28 PM  wrote:

> if rl.IsKeyDown(rl.KeyA) { p.Rect.X-- }
> if rl.IsKeyDown(rl.KeyD) { p.Rect.X++ }
> if rl.IsKeyDown(rl.KeyW) { p.Rect.Y-- }
> if rl.IsKeyDown(rl.KeyS) { p.Rect.Y++ }
>

It's worth mentioning though that this will not survive a gofmt.

In general, I've found that Go does not provide a lot of options to shorten
code like this especially if you, like most people, use gofmt. There have
been times when this has frustrated me too, but I do think your original
code is the easiest solution to read.


> On Wednesday, May 1, 2019 at 8:38:10 PM UTC+8, гусь wrote:
>>
>> if rl.IsKeyDown(rl.KeyA) {
>> p.Rect.X -= 1
>> }
>> if rl.IsKeyDown(rl.KeyD) {
>> p.Rect.X += 1
>> }
>> if rl.IsKeyDown(rl.KeyW) {
>> p.Rect.Y -= 1
>> }
>> if rl.IsKeyDown(rl.KeyS) {
>> p.Rect.Y += 1
>> }
>>
> --
> 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.


Re: [go-nuts] Go if else syntax .. suggested replacement

2019-04-25 Thread Tyler Compton
>
> There are many counter-examples. What is the likelihood that someone who
> is not familiar with the "?" operator will be familiar with the operators
> for getting (*) and dereferencing (&) a pointer. And what is "<-"?
> Certainly people not familiar with Go will initially be confused by
> operators related to channels.
>

>
If you allow people to use pointers, will they use pointers to pointers to
> pointers to pointers?
>

Sure, every language feature has a complexity cost and a chance for abuse.
However, the win for having pointers is, to me, a thousand times more
significant than that of the ternary operator, so it helps outweigh the
drawbacks that pointers introduce.


> On Thu, Apr 25, 2019 at 9:19 AM Sam Whited  wrote:
>
>> On Wed, Apr 24, 2019, at 14:08, Mark Volkmann wrote:
>> > Are there really developers that find this unreadable?
>> >
>> > color := temperature > 80 ? “red” : “green”
>>
>> Yes.
>>
>> What is "?"? If I've never seen that before I have no easy way to search
>> for that, and a random symbol me nothing about what it does. Go
>> specifically tries to stick to keywords because even if you've never
>> seen them before it's generally easier to figure out what they do (or to
>> search for them if you're not sure).
>>
>> Not to mention that even if you do know what they do, that specific
>> statement isn't the problem. If you allow people to do that, they'll end
>> up trying to nest it 5 levels deep. Go tries not to give people the
>> tools to shoot themselves in the foot for some tiny perceived advantage.
>>
>> —Sam
>>
>> --
>> 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.
>>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> --
> 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.


Re: [go-nuts] cracking the go language aplication

2019-04-17 Thread Tyler Compton
Could you provide some more details on what it is you want to do? Are you
looking to decompile a Go executable?

On Wed, Apr 17, 2019 at 12:23 PM smn shilla  wrote:

> Hi all
> Please anyone who know to crack the go application.exe please assist 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.
>

-- 
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] Question regarding gob

2019-03-26 Thread Tyler Compton
When we think of pointers as what they literally are, an address to a space
in memory, it sounds reasonable for Gob to not support them. Things get
more unclear when we consider that, in practice, Go programmers often use
pointers as a replacement for option types. Without pointers, I don't know
how an optional value could be transported using Gob, unless you're willing
to add an additional flag to your data structure to indicate if some data
is considered present.

On Tue, Mar 26, 2019 at 9:48 AM Michael Jones 
wrote:

> To be clear here as educators, it is important to point out that exporting
> / persisting / sending a pointer is an awkward concept.
>
> The normal meanings of sending data beyond an executing program have no
> direct use for the pointer’s literal value; “the thing at location 12345 in
> the memory of a program that ran last year” is not much help.
>
> On the other hand, one might imagine pointers being like file names and
> then recreate both content and references during reading. The export format
> could persist all the typed, pointed to values in tables, and then for each
> pointer variable exported send instead advice like “put the address of the
> 456th element of the table for type C things in this pointer slot.”
>
> A persistent format supporting this way of recreating the semantics of
> pointers is very much like an archive format (Zip) with support for
> symbolic links. It is not particularly hard to implement, but it is a
> “heavyweight” approach. My sense is that the common desire in export tools
> is high speed and byte efficiency so it is natural that Gob and other
> mechanisms adopt the “pointers don’t make sense for export” argument.
>
> Michael
>
> On Tue, Mar 26, 2019 at 6:01 AM roger peppe  wrote:
>
>>
>>
>> On Mon, 25 Mar 2019 at 14:45, Glen Huang  wrote:
>>
>>> Thanks for the reply, Sameer.
>>>
>>> Being able to directly send go types is a really big plus for me, I
>>> wonder if I really want to use gob, are there any recommended rpc choices?
>>>
>>
>> Note that gob has at least one significant limitation when encoding Go
>> types - it doesn't know about pointers - in general it encodes a pointer by
>> omitting a field. So if you want to send a slice of a pointer type where
>> some elements can be nil, you're out of luck:
>> https://play.golang.org/p/ThVUT_M0hjR
>>
>> --
>> 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.
>>
> --
>
> *Michael T. jonesmichael.jo...@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.
> 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] why go get does not work outside a module?

2019-02-15 Thread Tyler Compton
It sounds to me like you would want to set GO111MODULE to "auto". My
understanding is that then "go get" will behave like it used to when run
inside of the GOPATH or in a directory tree without a go.mod file.

Here's a bit of information about it on the wiki:
https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior


On Fri, Feb 15, 2019 at 6:23 AM Manlio Perillo 
wrote:

> I have started to use go modules recently, and I have set GO111MODULE=on.
>
> It was unexpected to found that go get does not work outside a module.
> As an example:
> $ go get github.com/davecheney/godoc2md
> go: cannot determine module path for source directory /home/manlio
> (outside GOPATH, no import comments)
>
> When I used go get inside a module I found that:
>
> 1. It saves the downloaded packages in the go mod cache
> 2. It Installs the command in GOBIN
>
> These two points can be also done outside a module.
>
> 3. Add an (indirect) entry in the require section in the go.mod file
>
> The new entry will, however, be removed by go mod tidy.
>
> Is it really necessary that go get must only work inside a module?
>
>
> Thanks
> Manlio Perillo
>
> --
> 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.


Re: [go-nuts] Mismatched types work sometimes?

2019-02-11 Thread Tyler Compton
Constant expressions like 'A' or 3 or named constants like "const x = 7"
are what Go calls "untyped constants". The type of these constants are
determined by the context in which they're used. For example:

const myConst = 3
myFloat := 2.5
fmt.Println(myFloat + myConst)
fmt.Println(myFloat + 3)

Both of the above cases work because myConst and the literal 3 are untyped
constants that take on the type float64 automatically.

You can also declare typed constants, which no longer have these type
inference properties.

const myConst int = 3
myFloat := 2.5
fmt.Println(myFloat + myConst)  // No longer works

If you're curious about the details, I would check out the section of the
language spec on this: https://golang.org/ref/spec#Constants

On Mon, Feb 11, 2019 at 9:37 AM Jamie Caldwell 
wrote:

> Hello,
>
> Can you help?
>
> https://play.golang.org/p/XfJZ3h06p60
>
> Why does 'A' work, when first assigning it to a variable doesn't?
>
> Thank you,
> Jamie.
>
> --
> 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.


Re: [go-nuts] Re: Providing more detail after a nil pointer dereference

2019-02-09 Thread Tyler Compton
Oh, and I just realized I linked completely the wrong issue. Here is a good
link: https://golang.org/issues/30116


On Sat, Feb 9, 2019 at 10:31 AM Tyler Compton  wrote:

> > A possibly better idea would be to report the line and column number.
> That should uniquely identify which code caused the problem, both for nil
> pointer and indexing. The question is how much additional space it would
> take to encode column numbers.
>
> I like this idea a lot though I admit that it probably wouldn't be worth a
> significant increase in binary size. Would doing this mean holding two
> integers (line, column) in the binary for every dereference? I could
> definitely see that getting expensive.
>
> > You can almost always disambiguate the problem dereference with some
> judicious uses of \n, if the problem is reproducible.
>
> This is the solution I've come up with too :) It usually is good enough,
> just not for those rare but nasty situations where a panic only happens
> occasionally and in production.
>
> Thanks for the insight!
>
> On Fri, Feb 8, 2019 at 8:10 PM 'Keith Randall' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> 27605 is more about providing the values that caused the panic, not the
>> source location. It is still the case that even with 27605 multiple
>> indexing operations on the same line are not distinguished (unless
>> knowledge of the application lets you disambiguate using the values).
>> For nil pointer dereferences, there's no value to report. Or, there's
>> exactly one value to report, which isn't helpful.
>>
>> Mentioning the variable is problematic for the reason you mentioned.
>>
>> A possibly better idea would be to report the line and column number.
>> That should uniquely identify which code caused the problem, both for nil
>> pointer and indexing. The question is how much additional space it would
>> take to encode column numbers.
>> You can almost always disambiguate the problem dereference with some
>> judicious uses of \n, if the problem is reproducible.
>>
>> On Thursday, February 7, 2019 at 4:36:01 PM UTC-8, Tyler Compton wrote:
>>>
>>> After reading https://golang.org/issues/27605 (proposal: report indexes
>>> for bounds failure), I started to wonder why we don't do something similar
>>> with nil pointer dereferences.
>>>
>>> I've more than once found myself in a situation where I'm inspecting a
>>> nil pointer dereference panic and it ends up on a line where any number of
>>> variables could have been the nil pointer in question. It would be helpful
>>> in these circumstances to get a message like "attempt to dereference
>>> variable 'myvar', which is a nil pointer" or something along those lines.
>>> Here is a toy example that causes a panic on a line where there are many
>>> variables that could have been the problematic nil pointer.
>>> https://play.golang.com/p/mmkOOU3M3lU
>>>
>>> My guess as to why I've never seen this in a language before is because
>>> dereferencing doesn't always happen on a named variable. For example,
>>> `getSomePointer().field` could result in a nil pointer dereference, but
>>> there's no variable name to put in the panic. Maybe then the panic message
>>> would be "attempt to dereference anonymous variable, which is a nil
>>> pointer", which is still slightly less ambiguous than the current panic
>>> message. Do you think a feature like this could be useful, even with its
>>> inherent limitations?
>>>
>> --
>> 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.


Re: [go-nuts] Re: Providing more detail after a nil pointer dereference

2019-02-09 Thread Tyler Compton
> A possibly better idea would be to report the line and column number.
That should uniquely identify which code caused the problem, both for nil
pointer and indexing. The question is how much additional space it would
take to encode column numbers.

I like this idea a lot though I admit that it probably wouldn't be worth a
significant increase in binary size. Would doing this mean holding two
integers (line, column) in the binary for every dereference? I could
definitely see that getting expensive.

> You can almost always disambiguate the problem dereference with some
judicious uses of \n, if the problem is reproducible.

This is the solution I've come up with too :) It usually is good enough,
just not for those rare but nasty situations where a panic only happens
occasionally and in production.

Thanks for the insight!

On Fri, Feb 8, 2019 at 8:10 PM 'Keith Randall' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> 27605 is more about providing the values that caused the panic, not the
> source location. It is still the case that even with 27605 multiple
> indexing operations on the same line are not distinguished (unless
> knowledge of the application lets you disambiguate using the values).
> For nil pointer dereferences, there's no value to report. Or, there's
> exactly one value to report, which isn't helpful.
>
> Mentioning the variable is problematic for the reason you mentioned.
>
> A possibly better idea would be to report the line and column number. That
> should uniquely identify which code caused the problem, both for nil
> pointer and indexing. The question is how much additional space it would
> take to encode column numbers.
> You can almost always disambiguate the problem dereference with some
> judicious uses of \n, if the problem is reproducible.
>
> On Thursday, February 7, 2019 at 4:36:01 PM UTC-8, Tyler Compton wrote:
>>
>> After reading https://golang.org/issues/27605 (proposal: report indexes
>> for bounds failure), I started to wonder why we don't do something similar
>> with nil pointer dereferences.
>>
>> I've more than once found myself in a situation where I'm inspecting a
>> nil pointer dereference panic and it ends up on a line where any number of
>> variables could have been the nil pointer in question. It would be helpful
>> in these circumstances to get a message like "attempt to dereference
>> variable 'myvar', which is a nil pointer" or something along those lines.
>> Here is a toy example that causes a panic on a line where there are many
>> variables that could have been the problematic nil pointer.
>> https://play.golang.com/p/mmkOOU3M3lU
>>
>> My guess as to why I've never seen this in a language before is because
>> dereferencing doesn't always happen on a named variable. For example,
>> `getSomePointer().field` could result in a nil pointer dereference, but
>> there's no variable name to put in the panic. Maybe then the panic message
>> would be "attempt to dereference anonymous variable, which is a nil
>> pointer", which is still slightly less ambiguous than the current panic
>> message. Do you think a feature like this could be useful, even with its
>> inherent limitations?
>>
> --
> 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] Providing more detail after a nil pointer dereference

2019-02-07 Thread Tyler Compton
After reading https://golang.org/issues/27605 (proposal: report indexes for
bounds failure), I started to wonder why we don't do something similar with
nil pointer dereferences.

I've more than once found myself in a situation where I'm inspecting a nil
pointer dereference panic and it ends up on a line where any number of
variables could have been the nil pointer in question. It would be helpful
in these circumstances to get a message like "attempt to dereference
variable 'myvar', which is a nil pointer" or something along those lines.
Here is a toy example that causes a panic on a line where there are many
variables that could have been the problematic nil pointer.
https://play.golang.com/p/mmkOOU3M3lU

My guess as to why I've never seen this in a language before is because
dereferencing doesn't always happen on a named variable. For example,
`getSomePointer().field` could result in a nil pointer dereference, but
there's no variable name to put in the panic. Maybe then the panic message
would be "attempt to dereference anonymous variable, which is a nil
pointer", which is still slightly less ambiguous than the current panic
message. Do you think a feature like this could be useful, even with its
inherent limitations?

-- 
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: multiple binaries from a single directory with go modules?

2019-01-18 Thread Tyler Compton
What alternative do you recommend?

On Fri, Jan 18, 2019 at 4:53 PM Space A.  wrote:

> Yes/ Don't use make and makefiles.
>
>
>
>> Is there some clever way of structuring a project like this with go
>> modules that I haven't figured out yet?
>>
>> Thanks,
>>
>> Tycho
>>
> --
> 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.


Re: [go-nuts] golang for coding interviews

2019-01-10 Thread Tyler Compton
Hi Naveen,

Others may disagree but my take is that Go is not a great coding interview
language. The lack of many built-in data structures is a big one, but those
closing curly braces and other syntax can be a big pain when writing on a
whiteboard. In cases where only general programming knowledge is being
tested for, I would pick Python so long as you're comfortable in the
language. It has more data structures available and is simply easier to
write on a whiteboard. Other conveniences like all, any, and list
comprehensions also come in handy when time to write code and available
space for code is at a premium.

Of course, traits that make a language better for interviews don't always
make the language better for production use. Go is still my go-to language
for many other things :)

On Thu, Jan 10, 2019 at 4:56 PM Naveen Neelakanta <
naveen.b.neelaka...@gmail.com> wrote:

> Hi All,
>
> I wanted to use Golang for coding interviews, however, I can't import
> basic data structures like stack, heap, the queue on to IDEs. Is there a
> way to achieve this.
>
> Thanks,
> Naveen
>
> --
> 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.


Re: [go-nuts] if/switch statements as expressions

2018-12-19 Thread Tyler Compton
There is some precedent. Python has an if expression of sorts that is
distinct from its if statements:

print(value1 if condition else value2)

And in all Lisp dialects I'm familiar with, if is an expression:

(print (if condition value1 value2))

Not to say that this means Go should support it necessarily.

On Wed, Dec 19, 2018 at 12:16 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Dec 19, 2018 at 9:09 PM Viktor Kojouharov 
> wrote:
>
>
> > I'm interested to know whether it was considered (I can't imagine that
> it wasn't) for if and switch statements to be expressions instead
>
> I can't imagine it was considered. Is there a precedence in other
> language? Not even C supports that.
>
>
> --
>
> -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.
> 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: pass interface

2018-12-10 Thread Tyler Compton
If my interpretation of the question is correct, I think it boils down to
whether or not it's possible to get the reflect.Type of a type in order to
pass it to a function without first creating an instance of that type. I
don't think it's possible but I would be interested to hear from someone
who knows more.

On Mon, Dec 10, 2018 at 1:28 PM Dan Kortschak  wrote:

> No, it is possible, but you need to pass the pointer to the interface.
> You can then use reflect to interrogate the interface value.
>
> The bigger question, and one that would help here would be what is it
> that you are actually trying to achieve.
>
> On Mon, 2018-12-10 at 08:53 -0600, Mark Volkmann wrote:
> > Yes, this is what I'm trying to do!
> > Perhaps this is not possible.
> >
> > On Sun, Dec 9, 2018 at 10:34 PM Robert Engels 
> > wrote:
> >
> > >
> > > I think what the OP wants is:
> > >
> > > type A interface{}
> > > type B interface{}
> > >
> > > ...
> > > PrintInterface(A)
> > >
> > > Meaning they want to pass the interface definition to some method.
> > >
> > > At least that’s what I am guessing.
> > >
> > > On Dec 9, 2018, at 9:22 PM, Space A.  wrote:
> > >
> > > reflect/* is a bit tricky. Use pointer to get interface itself.
> > >
> > > package main
> > >
> > > import (
> > > "fmt"
> > > "reflect"
> > > )
> > >
> > > func main() {
> > > test := interface{}("test")
> > > printInterfaceValue(test)
> > > }
> > >
> > > func printInterfaceValue(i interface{}) {
> > > switch testing := i.(type) {
> > > case interface{}:
> > > fmt.Println("is interface, with value:", testing)
> > > case string:
> > > fmt.Println("is not interface")
> > > }
> > >
> > > fmt.Println("reflect.Type is", reflect.TypeOf().Elem())
> > > }
> > >
> > > Output:
> > >
> > > is interface, with value: test
> > > reflect.Type is interface {}
> > >
> > >
> > >
> > >
> > >
> > >
> > > понедельник, 10 декабря 2018 г., 5:05:12 UTC+3 пользователь Robert
> > > Engels
> > > написал:
> > > >
> > > >
> > > > I mean reflect.Type not a type that is an interface.
> > > >
> > > > On Dec 9, 2018, at 6:53 PM, Space A.  wrote:
> > > >
> > > > Of course. When you "pass a value whose type implements the
> > > > interface" as
> > > > an interface argument to a function, you in fact pass an
> > > > *interface*.
> > > >
> > > >
> > > > воскресенье, 9 декабря 2018 г., 23:23:41 UTC+3 пользователь Mark
> > > > Volkmann
> > > > написал:
> > > > >
> > > > >
> > > > > Is it possible to pass an interface to a function in Go? I
> > > > > don’t want to
> > > > > pass a value whose type implements the interface, I want to
> > > > > pass the
> > > > > interface.
> > > > >
> > > > > --
> > > > > R. Mark Volkmann
> > > > > Object Computing, Inc.
> > > > >
> > > > --
> > > > 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.
> > >
> > > --
> > > 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.
> > >
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
>
> --
> 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.
>


-- 
Tyler Compton
Student of Software Engineering
Arizona State University

-- 
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: different behaviour in return: error is shadowed during return

2018-11-27 Thread Tyler Compton
As you are seeing, Go does not allow you to do a naked return when one of
the named return values is being shadowed by another variable. If you take
a look at the "Return statements" section in the Go Language Specification
[1], it mentions this restriction:

> Implementation restriction: A compiler may disallow an empty expression
list in a "return" statement if a different entity (constant, type, or
variable) with the same name as a result parameter is in scope at the place
of the return.

On line 203, it may look like err is being shadowed here, but it's not. The
:= operator will only define a new variable if a variable with that same
name hasn't already been defined in the same stack frame. On line 200,
m3u8List is being defined, but err is simply being assigned a new value.
This is because err is already defined in this stack frame in the form of a
named return variable.

On line 210, we're now in a new stack frame. Because of that, it is now
possible to redefine the err variable by shadowing the one defined as a
named return in the previous stack frame. Now that a named return variable
is being shadowed, naked returns will no longer compile. It's the rules :)

On line 216, we're no longer using a naked return, so the rule about
shadowing no longer applies.

As for why this restriction is in place, I'm not sure. I would be
interested to hear an explanation. However, I would assume it's to reduce
confusion. Naked returns can already be confusing, and adding shadowing
into the mix could make it very difficult to figure out what values are
actually being returned.

1. https://golang.org/ref/spec#Return_statements

On Tue, Nov 27, 2018 at 7:03 PM hui zhang  wrote:

> happen in  go 1.10.2   1.11.2
>
> 在 2018年11月28日星期三 UTC+8上午11:02:47,hui zhang写道:
>>
>> ./main.go:212:4: err is shadowed during return
>>
>> check code above only line 212 report err
>> however line 203 and 212 are almost the same case. but did not report 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.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Tyler Compton
Student of Software Engineering
Arizona State University

-- 
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: go modules and vendor: redundant features?

2018-11-21 Thread Tyler Compton
> People keep adding stuffs into Go and later find themselves unable to
remove existing features due to the backward compatibility promise. Go 1.11
is a different beast than Go 1.0, and is significantly more complex.

For what it's worth, I don't believe that tooling is covered under
the backward compatibility promise, so it is possible to remove things
without a new major version bump. Of course, this would have to be done
with care, but it's not out of the question. I know that this is a bit of
an aside but it's worth keeping in mind.

On Mon, Nov 19, 2018 at 4:40 PM  wrote:

>
> I recall reading from Russ Cox that vendoring will be removed in the
> future and be replaced by explicit caching with modules.
>
> --
> 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.
>


-- 
Tyler Compton
Student of Software Engineering
Arizona State University

-- 
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 modules and gocode

2018-11-09 Thread Tyler Compton
My understanding is the mdempsky branch is not expected to work with Go
modules. This fork apparently will: https://github.com/stamblerre/gocode

That said, I haven't personally had any luck with that fork either. I would
love to hear from someone who's had success with gocode/vim-go/modules.

On Fri, Nov 9, 2018 at 1:03 PM Keith Brown  wrote:

> Using vim-go
>
> Has anyone gotten gocode (https://github.com/mdempsky/gocode) to work
> with golang modules?
>
> In my GOPATH directory, i see
>
> gopath
>   pkg
> mod
>  cache
>download
>  github.com
>
> But for whatever reason, its not autocompletting the modules.
>
> Is there anything else I should be doing? In addion, is there a better
> solution for vim users?
>
>
> --
> 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.


Re: [go-nuts] Why fmt.Print() debug statements aren't showing up in dev_appserver.py logs?

2018-11-09 Thread Tyler Compton
App Engine's logging library requires a context object as its first
argument, so I'm not sure which log package you're using right now. The
correct way to use the App Engine logging library is to create a context
somewhere early on in the request's life-cycle and use it as the first
argument to the log functions.

ctx := appengine.NewContext(r)  // Where r is your *http.Request object
log.Infof(ctx, " handleMain() called")

Let me know what behavior you see doing this.

On Fri, Nov 9, 2018 at 1:15 PM Bryan  wrote:

> I replaced the fmt.Print statement  with:
>
> log.Infof(" handleMain() called")
>
> The local server still serves the page correctly but the log Info is not
> showing up in the dev_appserver.py logs in Terminal.
>
> On Thursday, November 8, 2018 at 5:57:06 PM UTC-5, Tyler Compton wrote:
>
>> I believe that the most correct way to do logging with App Engine is to
>> use the log package (https://godoc.org/google.golang.org/appengine/log).
>> This, to my understanding, allows App Engine to categorize logs based on
>> which request they are from alongside some other metadata. Do you see
>> printouts using this package?
>>
>> On Thu, Nov 8, 2018 at 1:02 PM Bryan  wrote:
>>
> The local webserver renders the page correctly at http://localhost:8080/
>>>
>>> I"m using the code from
>>> https://github.com/GoogleCloudPlatform/golang-samples/tree/master/appengine/helloworld
>>>
>>> I put a print statement at line 20 of hello.go :
>>>
>>> fmt.Print(" hello.handle() called")
>>>
>>> I'm starting the local server with:
>>>
>>> $ dev_appserver.py app.yaml
>>>
>>> Shouldn't the print statement be showing up in the osX Terminal window
>>> server logs?
>>>
>>> I could have sworn I was not having this issue a few weeks ago. How do I
>>> check that the wrapper is capable of processing STDOUT?
>>>
>>> How do I fix 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...@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.
>

-- 
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] Why fmt.Print() debug statements aren't showing up in dev_appserver.py logs?

2018-11-08 Thread Tyler Compton
I believe that the most correct way to do logging with App Engine is to use
the log package (https://godoc.org/google.golang.org/appengine/log). This,
to my understanding, allows App Engine to categorize logs based on which
request they are from alongside some other metadata. Do you see printouts
using this package?

On Thu, Nov 8, 2018 at 1:02 PM Bryan  wrote:

> The local webserver renders the page correctly at http://localhost:8080/
>
> I"m using the code from
> https://github.com/GoogleCloudPlatform/golang-samples/tree/master/appengine/helloworld
>
> I put a print statement at line 20 of hello.go :
>
> fmt.Print(" hello.handle() called")
>
> I'm starting the local server with:
>
> $ dev_appserver.py app.yaml
>
> Shouldn't the print statement be showing up in the osX Terminal window
> server logs?
>
> I could have sworn I was not having this issue a few weeks ago. How do I
> check that the wrapper is capable of processing STDOUT?
>
> How do I fix 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.
>

-- 
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:nosplit

2018-10-05 Thread Tyler Compton
I'm also surprised to hear that go:nosplit can be used in arbitrary
packages. I would be curious to know if these directives are covered under
the compatibility promise within the limited guarantees they provide.

On Fri, Oct 5, 2018 at 2:47 PM Scott Cotton  wrote:

> Thanks much for the info.
>
> Do you have any more pointers about how one may assess whether or ensure
> that a stack overflow check
> is not necessary in order to safely use this directive?
>
> Scott
>
>
> On Fri, 5 Oct 2018 at 23:26, Ian Lance Taylor  wrote:
>
>> On Fri, Oct 5, 2018 at 2:10 PM, Scott Cotton  wrote:
>> >
>> > I have for the longest time thought of "go:nosplit" as a
>> runtime-specific
>> > thing which wasn't available to arbitrary package authors.
>> >
>> > Then, I found this from "go doc compile"
>> >
>> > ```
>> > //go:nosplit
>> >
>> > The //go:nosplit directive specifies that the next function declared in
>> the
>> > file must not include a stack overflow check. This is most commonly
>> used by
>> > low-level runtime sources invoked at times when it is unsafe for the
>> calling
>> > goroutine to be preempted.
>> > ```
>> >
>> > I am interested in knowing
>> > 1. Can it indeed be used in arbitrary packages?
>>
>> Yes.
>>
>> > 2. Does it indeed prevent the emission/addition of pre-emption
>> instructions
>> > in the function it annotates?
>>
>> Well, yes and no.  What it does is disable the stack overflow check at
>> function entry.  At present the stack overflow check is also used  as
>> a goroutine-preemption check.  So disabling the stack overflow check
>> disables the goroutine-preemption check at function entry.  And in Go
>> 1.11 that is the only preemption check, so in Go 1.11 go:nosplit does
>> indeed disable preemption for a function.  But there are no promises
>> that there will never be any other sort of preemption check.  In fact
>> we definitely do want to add other preemption checks that occur at
>> points other than function entry (issues #10958, #24543).  And if
>> there is another preemption check, there are no promises that
>> go:nosplit will disable that check.
>>
>> > 3. Can it be used with gccgo?
>>
>> Yes.
>>
>> Ian
>>
>
>
> --
> Scott Cotton
> http://www.iri-labs.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.
> 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] Proposal: Implicit Method Signatures

2018-09-28 Thread Tyler Compton
When I do want to define my own custom getter, how might I tell the
language that my new method is a custom getter and not just a method with
no arguments and one return value? I think if Go were to have properties,
they would have to be explicitly marked as a property in some way to avoid
this.

For what it's worth, I'm personally mixed on properties. They do provide a
nice syntax for accessing information from an object but they can sometimes
make it harder to see what's going on in a program. When I read code in
languages with properties, it can be hard for me to know which expressions
result in some external code being run and which ones don't.

On Fri, Sep 28, 2018 at 3:45 PM 'Peter Müller' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> The other day I had an interesting idea: What if all exported fields have
> an implicit getter. Like e.g.
>
> type Human struct {
> Age  uint
> Name string
> }
>
> would implicitly get the methods:
>
> func (h Human) Name() string {
> return h.Name
> }
> func (h Human) Age() uint {
> return h.Age
> }
>
>
> *When defining an interface*
>
> type Being interface {
> Age()  uint
> Name() string
> }
>
> getters would not have to be defined if they simply return a property.
> This would remove boilerplate code. But if a modification or calculation is
> needed you would just make a private property and define a custom getter.
>
>
> *Backwards compatibility*
>
> Explicitly defined getters would be overriding the implicit ones and
> therefore not change behaviour of existing programs.
>
>
>
> This is only an idea. I post this to know if either this is a valid idea
> worth considering putting into go or if there is just something wrong with
> my style of coding and using interfaces.
>
> --
> 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.


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

2018-09-08 Thread Tyler Compton
I believe what you're discussing in this case is function or method
overloading. Operator overloading refers to the ability to specify custom
behavior for operators like +, -, etc.

On Sat, Sep 8, 2018 at 6:58 PM Rick 
wrote:

> With recent discussion concerning the possible introduction of generics in
> Go 2, it occurs to me to ask about support for operator overloading in Go
> 2. By this I mean support for functions having the same name but different
> signature:
>
> func foo(x int) int ...
>
> func foo(x string) bool ...
>
> func foo(x int, y string) ...
>
> etc.
>
> Is support for operator overloading implied by support for generics? Is it
> possible to have one with the other? To be honest, I've been more bothered
> by the lack of operator overloading than by the absence of generics. And (I
> assume) no new syntax would be required to support overloading. Or would
> there?
>
>
> --
> 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.


Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

2018-09-07 Thread Tyler Compton
I agree with Alan and I actually think the parentheses-based syntax is
fine. In Go as it is now, there is no case where using brackets on a
variable results in a call to code somewhere else in the project. It's
always some kind of indexing operation. Parenthesis have a history of doing
this with function calls. If we adopt the bracket syntax for generics, it
may become a bit harder when reading code to see which lines call out to
another part of the project and which lines don't. This is often a problem
with languages that support properties and operator overloading. I
appreciate Go's clarity in this matter and I think the bracket syntax might
undermine it a bit.

On Fri, Sep 7, 2018 at 6:31 AM  wrote:

> Whilst I could live with square brackets, I prefer round brackets too and
> still would do even if angle brackets were available.
>
> This is because when I see different types of brackets following an
> identifier, I (and probably many others) tend to associate them as follows:
>
> 1. square brackets  ->  arrays/slices/maps
>
> 2. curly brackets ->  function bodies, struct/interface declarations
>
> 3. angle brackets->  ordering operators
>
> 4. round brackets->  function declarations, function invocations, type
> conversions, grouping stuff together
>
> So I agree with rog that #4 best fits the existing Go ethos.
>
>
> On Friday, September 7, 2018 at 12:47:59 PM UTC+1, rog wrote:
>
>> Personally, I'm happy with the choice to use round brackets.
>>
>> Go started down this road a long time ago, in my view, by making type
>> conversions look like function calls.
>>
>> When `typename(x)` is qualitatively different from `value(x)`, I think
>> it's quite reasonable that `x(typename)` is qualitatively different
>> from `x(value)` too.
>>
>> In other words, I think it's nicely regular and fits Go's aesthetic well.
>>
>>
>> On 7 September 2018 at 09:05, Sebastien Binet  wrote:
>> > Bikesheding mode on...
>> >
>> > On Fri, Sep 7, 2018, 00:06 jimmy frasche  wrote:
>> >>
>> >> I'd quite prefer [] over (). It would make F[t](v) distinct from
>> >> F(x)(y) even if it's not distinct from m[x](y).
>> >
>> >
>> > One could add a dot, like for type checking:
>> > F.[T](y)
>> >
>> > Yet another rule to learn... :)
>> >
>> > -s
>> >
>> >
>>
> >> On Thu, Sep 6, 2018 at 3:02 PM Ian Lance Taylor 
>> wrote:
>> >> >
>> >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche 
>>
> >> > wrote:
>> >> > >
>> >> > > Wouldn't there be an issue with fp := AFunc[int] ?
>> >> >
>> >> > I don't think so.  AFunc[int] would be parsed as an index operation,
>> >> > and after name lookup it would resolve into either an array lookup
>> or
>> >> > a function instantiation, depending on the meaning of `int` in the
>> >> > current scope.  This is not very different from the way that t(v)
>> >> > resolves to either a function call or a type conversion after name
>> >> > lookup.  It's quite different from using <>, which has to be parsed
>> >> > quite differently depending on whether it is an instantiation or a
>> >> > comparison.
>> >> >
>> >> >
>> >> > > Though for that matter I wouldn't mind if the type part were
>> repeated
>> >> > > for instantiations like AFunc[type int] or even AFunc(type int)
>> >> >
>> >> > That would be possible but seems unnecessary.  I personally would
>> >> > prefer to avoid it.
>> >> >
>> >> >
>> >> > > For that matter, always writing type would let you use < > since
>> the
>> >> > > parser could plausibly enter a separate mode when it hit the <
>> token
>> >> > > followed by type.
>> >> > >
>> >> > > Noisy but obvious at a glance what's happening.
>> >> >
>> >> > Yes, that is true except for the >> issue.
>> >> >
>> >> > 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...@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.
>

-- 
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: Os/Exec problematic quotation marks

2018-09-05 Thread Tyler Compton
Oh, you beat me to it :) Good luck on your project!

On Wed, Sep 5, 2018 at 9:35 AM Tyler Compton  wrote:

> I believe what Volker is suggesting is to create your command in this way:
>
> cmnd := exec.Command("C:/Program Files/internet explorer/iexplore.exe",
> "--nogui", "--start", "AGT_BANCL_CobrosManuales")
>
> Have you given this a shot? The exec.Command function expects each
> space-separated argument of the command to be a separate argument. I
> suspect that exec.Command is seeing spaces in the one argument you're
> giving it and assuming it needs quotes.
>
> On Wed, Sep 5, 2018 at 9:17 AM Daniel Estiven Rico Posada <
> danielrico.pos...@gmail.com> wrote:
>
>> Yeah, but i want that when i execute an application from Go exec, be the
>> same that if i executed from cmd directly. But actually, the execution from
>> go exec have quotation marks in the args.  is there something possibility?
>>
>>
>>
>> El miércoles, 5 de septiembre de 2018, 3:32:44 (UTC-5), Daniel Estiven
>> Rico Posada escribió:
>>>
>>> Hello,
>>>
>>> Actually i'm working in a go application that receive a http request and
>>> start some windows assistants. (RPA's)
>>>
>>> The assistants are executed from windows cmd:
>>> > "C:/path/file.exe" --args
>>>
>>> When i start the assistant from cmd manually, in the task Manager i see
>>> the arguments without quotation marks. But if i open the assistant from go
>>> application the arguments are left with quotation marks.
>>>
>>>
>>>
>>> In golang i'm using the lib *"os/exec":*
>>>
>>> Internet explorer is only an example.
>>>
>>> *Do you know what's the reason?*
>>>
>>> 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.
>>
>

-- 
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: Os/Exec problematic quotation marks

2018-09-05 Thread Tyler Compton
I believe what Volker is suggesting is to create your command in this way:

cmnd := exec.Command("C:/Program Files/internet explorer/iexplore.exe",
"--nogui", "--start", "AGT_BANCL_CobrosManuales")

Have you given this a shot? The exec.Command function expects each
space-separated argument of the command to be a separate argument. I
suspect that exec.Command is seeing spaces in the one argument you're
giving it and assuming it needs quotes.

On Wed, Sep 5, 2018 at 9:17 AM Daniel Estiven Rico Posada <
danielrico.pos...@gmail.com> wrote:

> Yeah, but i want that when i execute an application from Go exec, be the
> same that if i executed from cmd directly. But actually, the execution from
> go exec have quotation marks in the args.  is there something possibility?
>
>
>
> El miércoles, 5 de septiembre de 2018, 3:32:44 (UTC-5), Daniel Estiven
> Rico Posada escribió:
>>
>> Hello,
>>
>> Actually i'm working in a go application that receive a http request and
>> start some windows assistants. (RPA's)
>>
>> The assistants are executed from windows cmd:
>> > "C:/path/file.exe" --args
>>
>> When i start the assistant from cmd manually, in the task Manager i see
>> the arguments without quotation marks. But if i open the assistant from go
>> application the arguments are left with quotation marks.
>>
>>
>>
>> In golang i'm using the lib *"os/exec":*
>>
>> Internet explorer is only an example.
>>
>> *Do you know what's the reason?*
>>
>> 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.
>

-- 
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] Cross platform native(no dependencies) GUI options.

2018-05-27 Thread Tyler Compton
I did a bit more research and found https://github.com/BurntSushi/xgb which
interacts with X directly without the need for C bindings, so it is
possible to at least open a window without any cgo. However, I don't know
of a way that you can have cross-platform accelerated graphics without
using OpenGL, which will require cgo. Unfortunately, I'm not sure if what
you want is really feasible, and if it is you may not be very happy with
the results.

There are GUI libraries out there for Go that require cgo but support all
major platforms. What is it about cgo that you're hoping to avoid?

On Sun, May 27, 2018 at 2:57 PM <ati...@mail.ccsf.edu> wrote:

> I just do not want it to have cgo and it should be perfect.
>
>
> On Sunday, May 27, 2018 at 2:55:06 PM UTC-7, Tyler Compton wrote:
>
>> I'm not sure if it's actually feasible to write a GUI library without
>> external libraries. A GUI that runs Linux will need to interact with an X
>> server or a Wayland compositer, and the library will have to interact with
>> their APIs somehow.
>>
>> On Sun, May 27, 2018, 14:19 <ati...@mail.ccsf.edu> wrote:
>>
>>> Yeah, the ones suggested all use cgo though.
>>>
>>>
>>> On Sunday, May 27, 2018 at 2:08:17 PM UTC-7, Sebastien Binet wrote:
>>>
>>>> There was very recently a thread about this on Reddit:
>>>>
>>>>
>>>> https://www.reddit.com/r/golang/comments/8m5icy/cross_platform_native_gui_library/
>>>>
>>>> sent from my droid
>>>>
>>>> On Sun, May 27, 2018, 22:51 <ati...@mail.ccsf.edu> wrote:
>>>>
>>> Hello,
>>>>>
>>>>> I would like you guys to suggest some GUI libraries that do not have
>>>>> any HTML/CSS or C bindings, are cross platform and require no 
>>>>> dependencies.
>>>>>
>>>>> When I say native, I mean no dependencies. I do not mean native to the
>>>>> OS. This would be great but I don't see any available that have no C
>>>>> bindings. I understand that to create a native to the OS experience there
>>>>> must be calls to the OS API which in most cases use the C language.
>>>>>
>>>>> Before anyone asks why I do not want C bindings, it is because they do
>>>>> not have good cross compilation support or good compile speeds.
>>>>>
>>>>> Suggestions appreciated, Thanks so much!
>>>>>
>>>>> --
>>>>> 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.
>

-- 
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] Cross platform native(no dependencies) GUI options.

2018-05-27 Thread Tyler Compton
I'm not sure if it's actually feasible to write a GUI library without
external libraries. A GUI that runs Linux will need to interact with an X
server or a Wayland compositer, and the library will have to interact with
their APIs somehow.

On Sun, May 27, 2018, 14:19  wrote:

> Yeah, the ones suggested all use cgo though.
>
>
> On Sunday, May 27, 2018 at 2:08:17 PM UTC-7, Sebastien Binet wrote:
>
>> There was very recently a thread about this on Reddit:
>>
>>
>> https://www.reddit.com/r/golang/comments/8m5icy/cross_platform_native_gui_library/
>>
>> sent from my droid
>>
>> On Sun, May 27, 2018, 22:51  wrote:
>>
> Hello,
>>>
>>> I would like you guys to suggest some GUI libraries that do not have any
>>> HTML/CSS or C bindings, are cross platform and require no dependencies.
>>>
>>> When I say native, I mean no dependencies. I do not mean native to the
>>> OS. This would be great but I don't see any available that have no C
>>> bindings. I understand that to create a native to the OS experience there
>>> must be calls to the OS API which in most cases use the C language.
>>>
>>> Before anyone asks why I do not want C bindings, it is because they do
>>> not have good cross compilation support or good compile speeds.
>>>
>>> Suggestions appreciated, Thanks so much!
>>>
>>> --
>>> 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.
>

-- 
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] Global variable not used, but it works fine

2018-04-22 Thread Tyler Compton
Go does not flag unused global variables, it is intended functionality.
I've personally found that unused global variables have a higher chance at
being benign than local variables, but there's probably an argument to be
made for flagging globals, too.

On Sat, Apr 21, 2018, 06:30  wrote:

>  What did you do?
> https://play.golang.org/p/aryK9Btv5kH
>
>  What did you expect to see?
> There should be a error "declared and not used"
>
>  What did you see instead?
> It seems work fine.
>
>  System details
>
> ```
> go version go1.10.1 windows/amd64
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="C:\Users\zps\AppData\Local\go-build"
> GOEXE=".exe"
> GOHOSTARCH="amd64"
> GOHOSTOS="windows"
> GOOS="windows"
> GOPATH="C:\Users\zps\go"
> GORACE=""
> GOROOT="C:\Go"
> GOTMPDIR=""
> GOTOOLDIR="C:\Go\pkg\tool\windows_amd64"
> GCCGO="gccgo"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments
> -fmessage-length=0
> -fdebug-prefix-map=C:\Users\zps\AppData\Local\Temp\go-build846935694=/tmp/go-build
> -gno-record-gcc-switches"
> GOROOT/bin/go version: go version go1.10.1 windows/amd64
> GOROOT/bin/go tool compile -V: compile version go1.10.1
> ```
>
> --
> 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.


Re: [go-nuts] formatting question/issue

2018-04-09 Thread Tyler Compton
My understanding is that this is a consequence of the semicolon insertion
rules Go uses. The Go parser actually uses semicolons internally, but they
are inserted before parsing so that the programmer doesn't have to.

Semicolons are added to the end of a line if the line ends with:
 - an identifier
 - an integer, floating-point, imaginary, rune, or string literal
 - one of the keywords break, continue, fallthrough, or return
 - one of the operators and delimiters ++, --, ), ], or }
(Taken from this article:
https://medium.com/golangspec/automatic-semicolon-insertion-in-go-1990338f2649
)

In your second example on line 18, "true" is an identifier so a semicolon
would be inserted there. Obviously this would make for invalid code,
because that place is not the end of an expression. Adding a comma lets the
semicolon inserter know that there is more to this expression so it doesn't
add a semicolon.

It's an interesting suggestion to make the comma obligatory. My first
impression is that it would lead to even more surprises to programmers from
other languages.

On Mon, Apr 9, 2018 at 4:32 PM Alex Dvoretskiy 
wrote:

> Hello Golangnuts,
>
> Why there is no difference if the last comma exists?
>
> {'A', 'B', 'C', 'E'}
> or
> {'A', 'B', 'C', 'E',}
>
> both are valid.
>
>
> Sometimes it causes little troubles. For example, the second snippet
> wouldn't compile, because of different formatting. But these two snippets
> are identical technically. So, you have to add this last comma to keep the
> formatting you want. Which can be annoying.
>
> https://play.golang.org/p/4Vav9n2_NIc
>
> https://play.golang.org/p/pr2h6_FBxFn
>
>
> I think it's very good idea to make the last comma obligatory.
>
> --
> 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.


Re: [go-nuts] Re: Language is a platform, which golang still does not pay attention to !!!

2018-04-05 Thread Tyler Compton
Go does not run in a VM like JVM and CLR languages do, but Go provides a
"language as a platform"-like feel by allowing for code that is by and
large platform-independent. It is true that executables have to be built
for each platform but that has benefits of its own. Java applications
require the JVM to be installed, while Go executables work immediately on
the platform without dependencies.

Additionally, I don't really see why having a VM (which I assume is what
you mean by a platform) makes for better language in the cloud space. For
the most part, machines running in the cloud use Linux. If you build your
executable for Linux, you're done. No extra environment configuration
required like one would have to do to run a VM language. Building the
executable is often easy because of Go's great cross-compilation support.
This ease of deployment is something people talk up Go for quite a bit.

If you try Go out, I suspect you won't miss the JVM or the CLR.

On Thu, Apr 5, 2018 at 1:47 PM T L  wrote:

>
>
> On Thursday, April 5, 2018 at 1:26:19 PM UTC-4, bingj...@gmail.com wrote:
>>
>> Almost 10 years golang appears in the world. 10 years is not a short
>> duration. I think if it is not popular until 2020, it will never be popular.
>>
>> Golang is designed for cloud and internet areas. Really?
>>
>> The creators of golang have a lot of experience in C and C++. And golang
>> borrows features from C and C++. But C and C++ do not fit the requirements
>> of cloud and internet areas.
>>
>> Let's look at two popular programming languages java and php. What is the
>> most important features of these two languages? Simple, ugly but
>> practical... I find one feather: they are both not just programming
>> languages but also platforms. They are almost the same in Windows and
>> Linux. That's why java and php are very popular in recent days.
>>
>> C and C++ are just pure programming languages, not platforms. On Unix and
>> Windows, C and C++ are very different. A developer of windows C++ is not a
>> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>>
>> If golang wants to be widely used by developer all over the world before
>> 2020, it must learn some thing from java and php, must be a
>> programming-language-is-a-platform.
>>
>> Until now, programs written in golang still does not have binary
>> distribution format like jar, dll or so. People have to share libraries by
>> source code. It is so foolish.
>>
>
> https://golang.org/cmd/go/#hdr-Build_modes
>
>
>> Yes, Golang is very like C and C++, which are only pure programming
>> language, But this times, we need "language as/is platform" technologies,
>> just like php and java.
>>
>> I have watched golang for many years, but never turn to it. Why? I think
>> it is still semi-finished product. Creators of golang are researchers, not
>> engineers, they worked 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.
>

-- 
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: Experience Report building OCR in Go

2018-01-18 Thread Tyler Compton
In the Error Handling section, you mention having to write a special
package to capture stack traces. Would https://github.com/pkg/errors have
done what you want?

On Tue, Jan 16, 2018 at 6:18 AM Tad Vizbaras  wrote:

> I used "walk" for prototyping but found it too complex. I do not mean this
> as criticism. "walk" uses many closures to init controls and
> get GUI working. This is fine if you are into this style of programming. I
> find reading "walk" internal code challenging.
>
> "walk" was an inspiration. It is possible to build Go Windows GUI apps
> without C compiler.
>
> In terms of timing it took 1 solid month by 1 developer to get Windows GUI
> packages working.
>
>
>
> --
> 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.


Re: [go-nuts] Re: lambda syntax

2017-11-22 Thread Tyler Compton
It's usually best to create a new thread instead of responding to one
that's so old (more than three years in this case).

On Wed, Nov 22, 2017 at 6:28 AM  wrote:

> I don't know how you can live without Generics but you can't live without
> Lambda expression. No Go Authors will not listen to anyone.
> If I could(because of the project I am working on) I would never use a
> language like Go and would never look back. There are much better choices
> out there.
>
> On Wednesday, February 5, 2014 at 1:10:35 PM UTC-5, Felix wrote:
>>
>> Go as a language made a choice to leave certain things out, because
>> there is other ways to solve them, I live without generics and am happy,
>> no while loop no problem and etc.
>>
>> But am hoping that the entire Go community + Go team + who ever it may
>> concern
>> that we all accept that we need a lambda syntax,
>>
>> ---
>>
>> (input parameters) => expression
>>
>> ---
>>
>> (x, y) => x == y
>>
>> ---
>>
>> () => SomeMethod()
>>
>> ---
>>
>> this will really help with things like
>> implementing linq like in go check
>> https://github.com/ahmetalpbalkan/go-linq
>> (
>> https://groups.google.com/forum/#!topicsearchin/golang-nuts/lambda%7Csort:date%7Cspell:true/golang-nuts/L-kxltsynh0
>> )
>>
>> Am looking at the lambda expression from C#
>> http://msdn.microsoft.com/en-us/library/bb397687.aspx
>> this will make functional things nice in Go
>>
>> implementing a map over a slice like
>>
>> arr := []int{2, 3, 4}
>> map(x => x * 2, arr)
>>
>> simpler that
>> map(func(x int){ x * 2}, arr)
>>
>> So please Command Pike don't tell me no :-)
>>
> --
> 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.


Re: [go-nuts] Re: Go Code Debugging

2017-11-22 Thread Tyler Compton
If you're looking for an Eclipse-like IDE experience, you may also want to
check out Goland. I don't personally use it but I've heard a lot of good
things about it and it has debugging support.

On Wed, Nov 22, 2017 at 8:47 AM  wrote:

> I think it's a nightmare to set Eclipse up to support Go. Here's a 20
> minute tutorial:
>
> https://www.youtube.com/watch?v=v6Wn5gUSEwM
>
> If you fancy swapping editor, try Visual Studio Code. It's Go support is
> second to none (just install the Go plugin and you're done) and has
> excellent debugging support.
>
> On Wednesday, 22 November 2017 13:28:39 UTC, shanthku...@gmail.com wrote:
>>
>>
>>
>> Hi Go Experts,
>>
>>  Could you please share steps to debug go code using breakpoints in
>> eclipse?
>>
>>  Does it requires any third party tool.?
>>
>>
>> *Thanks and Regards*
>> *Shantkumar.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.
>

-- 
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: awesome-go project on golang github organization

2017-10-25 Thread Tyler Compton
It may not be a good idea to put the burden of awesome-go on the Go team,
since it's been pointed out in the past that they don't have extra cycles.
I suspect that's still the case.

On Tue, Oct 24, 2017 at 4:08 PM Dan Kortschak 
wrote:

> I have similar sentiments.
>
> On Tue, 2017-10-24 at 09:19 -0700, prades.m...@gmail.com wrote:
> > I submitted several original projects i made to your list, they
> > passed all
> > the tests, they sat in the pull-request list for 6 month then when
> > rejected
> > for disingenuous or unspecified reasons.So I would prefer not your
> > list
> > becomes the official one.
> >
>
> --
> 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.


Re: [go-nuts] Go 2 suggestion - Types like "int?"

2017-08-19 Thread Tyler Compton
I don't think it's immediately obvious what use cases this "int?" proposal
delivers that aren't covered by "*int". The encoding/json package uses
pointers to support null JSON values.

As a more general point, when someone answers your question, they're taking
time out of their day to help you. I think it's reasonable for the burden
of proof to be put upon the asker, who is looking to others for help.

On Sat, Aug 19, 2017 at 9:28 PM Tong Sun  wrote:

> Oh yeah? Are you sure what you are answering is what I'm asking?
>
> Please try to understand what people are asking before showing off
> yourself, or post concrete example to proof that you understand correctly
> what people are asking.
>
> On Sat, Aug 19, 2017 at 4:02 PM, Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> Go can do what you want today, just that it's spelled "*int".
>>
>> On Sat, Aug 19, 2017 at 6:01 PM, Tong Sun  wrote:
>>
>>> - "int?" will be a different type than "int". I.e., we know very well
>>> what we are sacrificing when we choose that type.
>>> - There is a demand there, json and/or sql. Denying it won't make it go
>>> away.
>>>
>>> (*Sorry to Jan, was sending to the wrong place*)
>>>
>>> On Sat, Aug 19, 2017 at 11:54 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>>
 On Sat, Aug 19, 2017 at 5:05 PM Tong Sun  wrote:

 > Suggesting C# type syntax like "int?" so as to take nil as valid
 value.

 - As int is not a pointer type, what would nil int mean?

 - Are you willing to sacrifice extra storage for the additional isNil
 information or do you prefer that int cannot represent 2^(sizeof(int)*8)
 different values?

 - (xyproblem?) If you need the information like 'isValid', why a
 separate bool [field] is not enough?

 --

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

-- 
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] "find" for Slices like "append"

2017-08-09 Thread Tyler Compton
I think Christoph is asking the right question here. If the code you're
writing requires you to search through collections of many different types
all across the code base, it may make sense to use a language like Python
with in-language support for searching. I think the more likely scenario is
that searching through collections is a trivial part of the overall program.

I think it would be worth working with the language for a bit and providing
an experience report perhaps alongside a proposal if this issue ends up
being as serious as you expect.

On Wed, Aug 9, 2017 at 12:54 AM Jan Mercl <0xj...@gmail.com> wrote:

>
>
>
> On Wed, Aug 9, 2017 at 9:10 AM  wrote:
>
> > , why not, "equals" is already defined), ...
>
> Does []float64{1, NaN, 2} contain a NaN? Using the defined equality the
> answer is no.
>
> --
>
> -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.
> 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] Offline Go Documentation Tools

2017-08-09 Thread Tyler Compton
> Is Visual Studio Code a .Net app that takes up lots of memory and CPU?

Worse, it's an Electron app :)
I don't personally use VSC, so I can't speak to its performance or
efficiency. However, LSP is currently supported at some level in Neovim
using a plugin, and first-class support is planned. It's possible that
there's a project to implement LSP in your editor of choice already.

On Mon, Aug 7, 2017 at 7:33 PM me  wrote:

>
>
> On Monday, July 24, 2017 at 2:52:48 PM UTC-6, Rob 'Commander' Pike wrote:
>>
>> The "go doc" (distinct from "godoc") command works fine offline. It fact
>> it never goes on line.
>>
>> -rob
>>
>>
> That's a good tip, I might be even able to use that and pipe it into an
> editor Memo/Edit widget for instant help with an F1 shortcut. Some editors
> have "tools" that you can pipe the output of a process into a status memo
> based on the context (current selected item in editor or cursor). Just
> running it at a command line and reading it like a man page is an option,
> but, I'll likely want something a bit more than that, such as a pop up
> window when I hit F1 or a shortcut.
>

-- 
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] Twitter search go code

2017-08-03 Thread Tyler Compton
I don't believe Shawn was trying to be condescending. He didn't link you to
https://lmgtfy.com/ after all ;)

You're likely to get better responses if you include info about your use
case and the libraries you have looked at so far.

On Tue, Aug 1, 2017 at 7:34 PM Tong Sun  wrote:

>
>
> On Wednesday, July 26, 2017 at 2:07:30 PM UTC-4, Shawn Milochik wrote:
>
>> On Wed, Jul 26, 2017 at 11:47 AM, Tong Sun wrote:
>>
>>> Any simple go code out there that can search Twitter? Thx.
>>>
>>
>> With a question this broad, you'd get much better and faster results by
>> using Google.
>>
>
> Funny there are people out there showing off by saying that they can
> do Google search, as if no one else knows it but he.
>
> , so impatient, judgmental and condescending.
> If you had paid a little more attention, it is not at all so broad as you
> think. Now read it again --
> The keywords are: "*simple*" and "*search*".
> The monster tool that emphasizes on *re-tweeting* does NOT qualify as the
> answer. Period.
>
> Luckily, with a bit more patient, I'm able to find a *simple* go code
> that *can* *search* Twitter --
> https://github.com/cathalgarvey/sqrape/blob/master/examples/tweetgrab.go
>
> Nice one!
>
> Going along that direction, I think the cascadia
>  the command line tool is even more
> simpler, in a sense of less dependency and less/no Go coding:
>
> $ cascadia -i 
> 'https://twitter.com/search?q=%22Gas%20Price%20Alert%22%20%23GTA%20from%3AGasBuddyDan=typd'
>  -o -c 'div.stream div.original-tweet div.content' --piece Time='small.time' 
> --piece Tweet='div.js-tweet-text-container > p'
> TimeTweet
>
>   Jul 31
> Gas Price Alert #Toronto #GTA #Hamilton #Ottawa #LdnOnt #Barrie 
> #Kitchener #Niagara #Windsor N/C Tues and to a 2ct/l HIKE gor Wednesday
>
>   Jul 6
> Gas Price Alert #Toronto #GTA #LdnOnt #Hamilton #Ottawa #Barrie #KW 
> to see a 1 ct/l drop @ for Friday July 7
>
>   May 30
> Gas Price Alert #Toronto #GTA #Ottawa #LdnOnt #Hamilton #KW #Barrie 
> #Windsor prices won't change Wednesday but will DROP 1 ct/l Thursday
>
>   May 15
> Gas Price Alert #Toronto #GTA #Barrie #Hamilton #LdnOnt #Ottawa #KW 
> #Windsor NO CHANGE @  except gas bar shenanigans for Tues & Wednesday
>
>   Mar 7
> Gas Price Alert #Toronto #GTHA #LdnOnt #Ottawa #Barrie #KW #Windsor 
> to see a 1 cent a litre HIKE Wed March 8 (to 107.9 in the #GTA)
>
>
>
> Check out the details at
> https://github.com/suntong/cascadia#twitter-search, which I updated just
> now.
>
>
>
> --
> 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.


Re: [go-nuts] Re: Go one-line installer

2017-08-03 Thread Tyler Compton
> No, most Linux users are used to installing from package managers.

I don't know if that's true. Many popular distributions provide undesirably
out-of-date versions of common tools and require users to use other means
to install them. But both of our assertions are valueless without data, so
it may not be worth discussing.

> Unless you were referring to installing Go in particular, where I
> conjecture that most Linux users who don't use some package manager
> to install Go, are installing from source.

I would have thought users would be more likely to reach for the pre-built
versions of Go, but again, we need data.

> I can't speak for Windows, but macOS (or OS X, or Mac OS X) never
> had executable installers like Windows had.

Fair enough, I admit I don't know a lot about the Mac sphere.

> The problem you are mentioning is the halting problem. There is no way
> reliably set configuration variables without solving the halting
> problem.
> I do not consider time spent on the halting problem to be productive
> time. Sorry.

I was referring to the problem of security, not the problem of
configuration variables. Certainly some of the security concerns with this
project can be addressed without solving the halting problem.


On Wed, Aug 2, 2017 at 6:50 AM  wrote:

> Hi,
>
> As you at this kind of work, have you considered a reliable one-liner to
> install dependencies ?
>
> I got that own, just today, from a gae repo (?), anyways here it is,
>
> go get -u -v $(go list -f '{{join .Imports "\n"}}{{"\n"}}{{join
> .TestImports "\n"}}' ./... | sort | uniq | grep -v golang-samples)
>
> Problem is, it did not quiet work for me when i put that into my travis :x
> https://travis-ci.org/mh-cbon/dht/jobs/260206514
>
> even when i restart the job.
>
> Do you have any ideas how to fix that ?
>
>
> thanks
>
>
> On Tuesday, August 1, 2017 at 9:42:00 PM UTC+2, Steve Francia wrote:
>
>> Greetings Gophers,
>>
>> I've been working on a "one line installer" for Go with Jess Frazelle and
>> Chris Broadfoot and we think it's ready to share a bit more broadly.
>>
>> The installer is designed to both install Go as well as do the initial
>> configuration of setting up the right environment variables and paths.
>> It will install the Go distribution (tools & stdlib) to "/.go" inside
>> your home directory by default.
>> It will setup "$HOME/go" as your GOPATH.
>>
>> If Go is already installed *via this installer* it will upgrade it to
>> the latest version of Go.
>>
>> Currently supported systems:
>>   linux, darwin, windows / amd64, 386 / bash, zsh, powershell
>>
>>
>> *Usage*
>> Windows Powershell:
>> (New-Object System.Net.WebClient).DownloadFile('
>> https://get.golang.org/installer.exe', 'installer.exe'); Start-Process
>> -Wait -NonewWindow installer.exe; Remove-Item installer.exe
>>
>> Shell (Linux/macOS/Windows):
>> curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x
>> go_installer && ./go_installer && rm go_installer
>>
>>
>> As we discovered developing this, installers are really all edge cases.
>> We're certain we've not found many of them.
>> *Our goal is that this becomes the primary mechanism to install Go. *
>> *To do that, we need your help testing, improving and fixing it. *
>>
>> The source can be found at
>> https://go.googlesource.com/tools/+/master/cmd/getgo/
>> If you find any issues please report them on Github
>> https://github.com/golang/go/issues/new?title=tools/cmd/getgo:
>>
>> 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.
> 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] Go one-line installer

2017-08-01 Thread Tyler Compton
> I was quite happy that the era of executable "installers" died once we
> got package managers.

This seems to come from a purely Linux perspective. I suspect that people
who use Linux are quite a bit less likely to benefit from this solution
anyway, because most Linux users are used to setting environment variables
and installing from tarballs. The era of executable installers has not died
on Windows or on Mac.

> If something is to be improved, perhaps the
> quality of packages for various distributions could be improved
> instead. That is what the users want anyway, to use their distro
> package manager.

Trying to improve every distro's Go version is a substantially more
difficult problem, and even worse, it's a bureaucratic one. I think it
would be a lot more productive to spend that time working on the technical
problem of security than giving up and tackling a much harder one.

On Tue, Aug 1, 2017 at 4:49 PM Florin Pățan  wrote:

> Hi,
>
> The idea is good but:
> - it needs to modify the path to add GOROOT/bin and GOPATH/bin to it
> - it should allow for multiple versions of Go to be installed
> simultaneously (including 1.x.y vs 1.x.z versions)
> - it should change the PATH on all three OSes regardless of the shell
> used, which is the hardest part I guess (as this is the part that trips
> over most of the people, along with the GOPATH requirement)
>
> Thank you.
>
> --
> 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.


Re: [go-nuts] Re: Experience using Go for a student projet

2017-07-30 Thread Tyler Compton
Hi Juliusz,

How did your students adjust to working with the GOPATH? I'm always
interested to see how newcomers react to it. It seems to cause some people
trouble.

On Sun, Jul 30, 2017, 12:14 PM Juliusz Chroboczek  wrote:

> > I glanced at babelweb2 (https://github.com/Vivena/babelweb2/). A code
> > review would be useful. For example, from parser/parser.go:
>
> Thanks for the review.  As I've mentioned, neither the students nor me
> had any significant experience with Go, so we were learning as we went
> along.
>
> If you happen to have another idle moment, a review of the channel
> structure will be welcome.
>
> Thanks again,
>
> -- Juliusz
>
> --
> 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.


Re: [go-nuts] Offline Go Documentation Tools

2017-07-24 Thread Tyler Compton
For cursor-sensitive help dialogs, you may find Language Server Protocol[1]
interesting. It provides what you're looking for in Visual Studio Code with
Go today, and will help provide that functionality to editors like [Neo]vim
in the future.

1. http://langserver.org/

On Mon, Jul 24, 2017 at 8:45 AM andrey mirtchovski 
wrote:

> > What do you use to read documentation when you are offline?
>
> godoc -http=:6060
>
> --
> 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.


Re: [go-nuts] What is Go's version of python's list data type?

2017-07-12 Thread Tyler Compton
If you're looking for a datatype in Go that stores multiple values, that
would be the slice. Slices are ordered collections of data that can change
in size at runtime.

myIntegers := []int{5, 7, 4, 3}
myStrings := []string{"hi", "there"}
myStrings = append(myStrings, "gophers")

The difference that Ian is alluding to is that slices in Go can only hold
elements that share the same type. We can seemingly get around this by
making a slice that holds values of type interface{}.

myThings := []interface{}{"str", 1234}

The interface{} type known as the "empty interface". Every type satisfies
the empty interface and therefore any instance of any type can be stored in
our slice. In practice, though, you won't often write code like this. I
would not recommend using slices of empty interfaces in most circumstances.

If you're someone who comes from a background of only dynamically typed
languages like Python, slices may seem a bit overly restrictive with their
type rules. In practice, though, this isn't generally a problem. You just
have to write code with static typing in mind. Without knowing what you
want to accomplish, however, it's hard to give a recommendation.

Of course, I don't know your background. You may have known all this
already :)

On Tue, Jul 11, 2017 at 9:49 PM Ian Lance Taylor  wrote:

> On Tue, Jul 11, 2017 at 9:20 PM,   wrote:
> >
> > A python list can be written as:
> >
> > ["something", 1234, 56.78, "Another string"]
> >
> > What is Go's data type that has a similar structure / capability?
>
> The literal answer to your question is
> []interface{}{"something", 1234, 56.78, "Another string"}
>
> A better answer would be: what are you trying to do?  Don't try to
> write Python in Go.  They are very different languages.
>
> 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.
> 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: gofmt question

2017-07-02 Thread Tyler Compton
Another nice aspect of this is that formatting consistency is
ecosystem-wide instead of company-wide.

On Sat, Jul 1, 2017 at 9:43 AM Shawn Milochik  wrote:

> On Sat, Jul 1, 2017 at 11:40 AM, Glenn Hancock  wrote:
>
>> Thanks for the responses.  I guess I'll just deal with it.  While I can
>> understand the need to format code the same way, I would rather have my
>> company policies dictate this instead of the all knowing Google force upon
>> me what they think is proper.  Guess we should get used to the new world
>> order. :-)
>>
>> Go still rocks though :-)
>>
>>
>>
> It's not Google. It's the Go team. Go is an open-source project. I'm sure
> plenty developers within Google itself have the same frustrations, until
> they get used to it. I certainly had some personal issues when I started
> with it, but now I don't notice or care at all anymore.
>
> Although you lose some in freedom in formatting your code, you gain a lot
> more thanks to having to expend precisely zero and time effort to
> formatting your code (if your editor runs gofmt/goimports automatically).
>
> --
> 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.


Re: [go-nuts] Curious about this snippet in /src/runtime/proc.go

2017-06-20 Thread Tyler Compton
Sent in a CL for some documentation on this.

https://github.com/golang/go/issues/20717
https://go-review.googlesource.com/#/c/46212/


On Mon, Jun 19, 2017 at 10:56 AM  wrote:

> It won't blank as much as it can get it's hands on. The default value for
> the pointer will be nil so it will try and assign (causing a panic()
> hopefully) to force an exit
>
> --
> 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.


Re: [go-nuts] Curious about this snippet in /src/runtime/proc.go

2017-06-15 Thread Tyler Compton
Very interesting. I'm not used to looking at Go code from the perspective
of an implementer of Go.

Somebody should contribute a comment about this upstream :)

On Thu, Jun 15, 2017 at 10:34 AM Ian Lance Taylor <i...@golang.org> wrote:

> On Thu, Jun 15, 2017 at 10:28 AM, Tyler Compton <xavi...@gmail.com> wrote:
> > Why not just panic, though? And why the infinite loop, I wonder?
>
> The runtime is a special case in many ways, and this is among the more
> special parts.  This loop exists to catch problems while testing new
> ports.  If that loop is ever reached, something has gone badly wrong:
> the exit call should have caused the program to exit.  We can't assume
> that panic is working.  We can't really assume that anything is
> working.  What we want to do is stop the program.  Since exit failed,
> it's possible that a nil dereference will succeed.  If that fails too,
> we still have to do something, so we just loop.  We can't return
> because this is the main function that started the program; there is
> nothing to return to.
>
> Ian
>
> > On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal <ald...@leal.eng.br> wrote:
> >>
> >> Force a panic in case exit fails?
> >>
> >> --
> >> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
> >>
> >> On Thu, Jun 15, 2017 at 4:54 AM, <goodwin.law...@gmail.com> wrote:
> >>>
> >>> Hey,
> >>>
> >>> Learning golang at the moment and came across this at the end of func
> >>> main() in proc.go in the golang source tree.
> >>>
> >>> exit(0)
> >>> for {
> >>> var x *int32
> >>> *x = 0
> >>> }
> >>>
> >>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
> >>>
> >>> How is the for loop ever reached and what's the purpose of the infinite
> >>> loop, zeroing memory?
> >>>
> >>> Thanks,
> >>>
> >>> Goodwin
> >>>
> >>> --
> >>> 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.
> >
> > --
> > Tyler Compton
> > Software Engineering
> >
> > --
> > 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.
>
-- 
Tyler Compton
Software Engineering

-- 
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] Curious about this snippet in /src/runtime/proc.go

2017-06-15 Thread Tyler Compton
Why not just panic, though? And why the infinite loop, I wonder?

On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal <ald...@leal.eng.br> wrote:

> Force a panic in case exit fails?
>
> --
> -- Aldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>
> On Thu, Jun 15, 2017 at 4:54 AM, <goodwin.law...@gmail.com> wrote:
>
>> Hey,
>>
>> Learning golang at the moment and came across this at the end of func
>> main() in proc.go in the golang source tree.
>>
>> exit(0)
>> for {
>> var x *int32
>> *x = 0
>> }
>>
>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
>>
>> How is the for loop ever reached and what's the purpose of the infinite
>> loop, zeroing memory?
>>
>> Thanks,
>>
>> Goodwin
>>
>> --
>> 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.
>
-- 
Tyler Compton
Software Engineering

-- 
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] Inspecting a function for its arguments with reflection

2017-03-21 Thread Tyler Compton
Thanks for the help! This is what I'm looking for.

On Mon, Mar 20, 2017 at 6:32 PM Marian Kopriva 
wrote:

> Check out https://github.com/go-martini/martini if you're looking for
> some magic.
> In case you don't find any magic there, then i'm sorry, i've havne't used
> martini myself, and am not familiar with its source, i've only heard from
> others that it's quite magicky.
>
> --
> 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.


Re: [go-nuts] Inspecting a function for its arguments with reflection

2017-03-20 Thread Tyler Compton
Also, if there already exists a library that does this kind of magic for
REST APIs, I'd love to hear about it.

On Mon, Mar 20, 2017 at 4:01 PM Tyler Compton <xavi...@gmail.com> wrote:

> I'm trying to create an HTTP request router library that automatically
> decodes parameters in the request URL and passes them as arguments to the
> handler function. It would theoretically make something like this possible:
>
> myRouter.HandleFunc("/getPuppies/{id}", func(w http.ResponseWriter, r *
> http.Request, id string) {
> // Handle the request
> });
>
> I am aware that you can't get the name of a function's arguments. That's
> okay with me, I can just pass the params in the order they appear. However,
> I do need to be able to check how many arguments a function has and what
> the types of those arguments are, so I can type assert the parameters and
> give sane error messages when the user makes a mistake.
>
> Before you point out that this is a bad idea and that reflection is never
> clear, I am fully aware! I'm doing this to learn about reflection in Go and
> to see if Go can support a workflow something like Java's JAX-RS.
>
> --
> 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] Inspecting a function for its arguments with reflection

2017-03-20 Thread Tyler Compton
I'm trying to create an HTTP request router library that automatically 
decodes parameters in the request URL and passes them as arguments to the 
handler function. It would theoretically make something like this possible:

myRouter.HandleFunc("/getPuppies/{id}", func(w http.ResponseWriter, r *http.
Request, id string) {
// Handle the request
});

I am aware that you can't get the name of a function's arguments. That's 
okay with me, I can just pass the params in the order they appear. However, 
I do need to be able to check how many arguments a function has and what 
the types of those arguments are, so I can type assert the parameters and 
give sane error messages when the user makes a mistake.

Before you point out that this is a bad idea and that reflection is never 
clear, I am fully aware! I'm doing this to learn about reflection in Go and 
to see if Go can support a workflow something like Java's JAX-RS.

-- 
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 use go generate to generate generic code .

2017-03-10 Thread Tyler Compton
If we assume a more useful generic task than writing a min function, what's
wrong with using code generation?

On Fri, Mar 10, 2017 at 6:14 AM Henry  wrote:

> If you insist on generics-like code generation:
> https://github.com/cheekybits/genny/blob/master/README.md
>
> --
> 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.


Re: [go-nuts] Can Go run on a calculator?

2017-02-22 Thread Tyler Compton
The TI-84 series uses the z80 instruction set, which isn't a compile target
in Go, unfortunately. That's not to say it couldn't be, but I bet there are
some more fundamental issues that would make compiling to a TI-84
impossible. I don't think Go supports any 8-bit machines.

On Wed, Feb 22, 2017 at 6:20 PM  wrote:

> I realized today that the TI-84 Plus C *Silver Edition* calculator I have
> is able to run assembly instructions, and after further Googling and some
> Wikipedia searches I found out that some C compilers exist. It uses the
> Zilog Z80 8-bit CPU with 128 KB of RAM (21 KB user accessible) and 4 MB of
> Flash ROM (3.5 MB user accessible), so I'm not expecting fireworks, but if
> I could get it to print "Hello World" we could successfully say Go runs on
> calculators (take that, Java!).
>
> Thanks,
> Meyer
>
> --
> 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.


Re: [go-nuts] Short vs. long variable declarations

2017-01-27 Thread Tyler Compton
While theoretically, I agree with your argument against using the short
variable declaration pattern, I've personally found that in practice it
isn't an issue. I think that if this is something you run into often, it
might suggest that you're letting too many variables into your scope,
whether that means having too many generically named global variables or
being inside too large a function.

On Fri, Jan 27, 2017, 11:57 AM Shawn Milochik  wrote:

> Here's a good discussion about it:
>
> https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ
>
> TL;DR: scope
>
> --
> 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.


Re: [go-nuts] why does runtime.GOMAXPROCS act like getter and setter?

2016-12-23 Thread Tyler Compton
The documentation suggests it's a temporary API, too:

"This call will go away when the scheduler improves."

I don't think it should be removed, though, even if it isn't included in
the compatibilty guarantee. I'd be surprised to hear if people have trouble
with its semantics. It's pretty simple, albiet clunky.

On Fri, Dec 23, 2016, 10:15 AM Michael Jones 
wrote:

> If it was to be changed, it might be good to add the pair:
>
> Gomaxprocs()
> SetGomaxprocs()
>
> I remember at the time it was suggested that it was "temporary API" that
> would go away someday. I have learned that there is rarely a temporary API,
> temporary utility, etc.
>
>
>
>
> On Fri, Dec 23, 2016 at 8:26 AM, Ian Lance Taylor  wrote:
>
> On Fri, Dec 23, 2016 at 12:44 AM, P Q  wrote:
> > runtime.GOMAXPROCS(n) behaves in two ways: getter if n < 1, otherwise
> > setter.
> >
> > For setter, does runtime.SetGOMAXPROCS(n) look good? The only reason
> behind
> > current behavior is the function is rarely used?
>
> Does anybody actually make a mistake here?  It's only worth fixing if
> it is causing a problem.
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Michael T. Jones
> michael.jo...@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.
> 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] Modern Garbage Collection Article

2016-12-19 Thread Tyler Compton
Thank you for your input!

> Throwing more cores at the problem is a sensible approach on modern 
hardware.  Since the cores are no longer getting faster, making your code 
run faster on a single core is not the optimal design for the hardware of 
the near future.

I had not considered increasing core counts as something that could drive 
such important decisions about GC design, but it makes sense. Now that I 
think of it, it falls right in line with Go's general goal of being useful 
on newer, multi-core machines.

Here is Rick Hudson's comment, for those who are 
interested: 
https://medium.com/@rlh_21830/it-is-not-true-that-without-compaction-fragmentation-is-inevitable-e67d111e#.fuuajmdoz

On Monday, December 19, 2016 at 10:31:52 PM UTC-7, Ian Lance Taylor wrote:
>
> On Mon, Dec 19, 2016 at 8:56 PM, Tyler Compton <xav...@gmail.com 
> > wrote: 
> > 
> https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7
>  
> > 
> > Thoughts? How accurate is this article? If it is, why, historically, is 
> the 
> > work being done on the GC so concentrated on pause times? 
>
> If you click on the comments link near the bottom you will see that 
> Rick has commented on part of the essay. 
>
> I do not work on the GC myself, but these are my personal observations. 
>
> I think the key observation in Go's GC is that modern systems have 
> multiple cores, and are rapidly getting more cores.  Throwing more 
> cores at the problem is a sensible approach on modern hardware.  Since 
> the cores are no longer getting faster, making your code run faster on 
> a single core is not the optimal design for the hardware of the near 
> future. 
>
> For a language like Go, stop-the-world pause times really are the most 
> important thing, because during a pause your server isn't doing 
> anything useful.  The essay suggests that the Go runtime is "willing 
> to slow down your program by almost any amount" in order to reduce 
> pause times; that is clearly hyperbole, and it isn't literally true. 
> The slowdowns in compiled Go code occur when writing pointers into the 
> heap and when allocating new memory.  The compiler works hard to let 
> you store variables on the stack rather than the heap, where no 
> slowdown occurs.  The language is designed to let you control when and 
> how memory is allocated, giving you control over when memory is 
> allocated.  The effect is that in Go you can adjust your program to 
> reduce GC overhead, rather than tuning the GC.  This is far more true 
> in Go than in Java, since Java has no stack variables or structs.  I'm 
> not familiar enough with C# to say anything serious about it. 
>
> That said, it should be obvious that nobody thinks that work on Go's 
> garbage collector has finished. 
>
> The essay mentions the request-oriented collector, which is indeed 
> similar to a generational garbage collector.  If everything works, the 
> request oriented collector can be cheaper than a generational 
> collector because no copying is required.  The essay suggests that it 
> can be simulated by a generational GC "by ensuring the young 
> generation is large enough that all garbage generated by handling a 
> request fits within it" but that is somewhat meaningless if any of 
> your requests can use a lot of memory, since you have to waste a lot 
> of space by allocating that much memory for each goroutine. 
>
> Once the request-oriented collector is working or abandoned, I believe 
> the GC team plans to focus on increasing throughput, since latency is 
> now low enough that it hopefully doesn't matter for non-realtime 
> programs. 
>
> 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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] Modern Garbage Collection Article

2016-12-19 Thread Tyler Compton
https://medium.com/@octskyward/modern-garbage-collection-911ef4f8bd8e#.c48w4ifa7

Thoughts? How accurate is this article? If it is, why, historically, is the 
work being done on the GC so concentrated on pause times?

For more 
discussion: 
https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/

-- 
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: Using EasyJSON with Golang

2016-11-14 Thread Tyler Compton
It looks like someone on Stack Overflow has answered your question[1].

You know your needs better than I do, but code generation seems like an 
unnecessarily complex way to unmarshal JSON code. I'd recommend taking a 
look at encoding/json[2] if you haven't already .

1. http://stackoverflow.com/a/40588324
2. http://golang.org/pkg/encoding/json

On Monday, November 14, 2016 at 4:41:50 AM UTC-7, DM wrote:
>
> Crossposting this from stackoverflow 
> :-
>
> Let's say I have a struct like below:-
>
> //easyjson:json
> type JSONData struct {
> Data []string}
>
> I want to un-marshal the below json to JSONData struct
>
> {"Data" : ["One", "Two", "Three"]} 
>
> Can someone let me know how can I use easyjson 
>  to un-marshal a json in Golang? I 
> could not find any example in their README
>

-- 
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: net/http: In the infinite loop, refused all requests.

2016-09-21 Thread Tyler Compton
This issue may be of interest to you:

https://github.com/golang/go/issues/10958

On Tuesday, September 20, 2016 at 7:42:24 PM UTC-7, Tony Chen wrote:
>
> ### What version of Go are you using (`go version`)?
> go 1.6.2 mac/amd64
>
> ### What operating system and processor architecture are you using (`go 
> env`)?
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/data/apps/go"
> GORACE=""
> GOROOT="/usr/local/go"
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> GO15VENDOREXPERIMENT="1"
> CC="clang"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 -fno-common"
> CXX="clang++"
> CGO_ENABLED="1"
>
> ### What did you do?
>
> package main
>
> import (
> "net/http"
> "strconv"
> "fmt"
> )
>
> func main() {
> http.HandleFunc("/", httpHandler)
> http.ListenAndServe(":8001", nil)
> }
>
> func httpHandler(w http.ResponseWriter, r *http.Request) {
> b, _ := strconv.ParseBool(r.URL.Query().Get("loop"))
> if b {
> loop()
> }
> fmt.Fprintf(w, "ok")
> }
>
> func loop() {
> i := 0
> for {
> if i == 1 {
> i = 0
> }
> i++
> }
> }
> 1. curl http://127.0.0.1:8001/?loop=true
> 2. curl http://127.0.0.1:8001/?loop=false
> When the loop to the CPU processing and about 8 times the request, refused 
> to all the HTTP request.
> ### What did you expect to see?
>
> export GODEBUG=schedtrace=1000
> SCHED 1010ms: gomaxprocs=8 idleprocs=8 threads=6 spinningthreads=0 
> idlethreads=3 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 2016ms: gomaxprocs=8 idleprocs=8 threads=6 spinningthreads=0 
> idlethreads=3 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 3019ms: gomaxprocs=8 idleprocs=8 threads=6 spinningthreads=0 
> idlethreads=3 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 4028ms: gomaxprocs=8 idleprocs=7 threads=6 spinningthreads=0 
> idlethreads=2 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 5033ms: gomaxprocs=8 idleprocs=5 threads=6 spinningthreads=0 
> idlethreads=0 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 6033ms: gomaxprocs=8 idleprocs=3 threads=8 spinningthreads=0 
> idlethreads=0 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 7035ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 8037ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 9044ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 10050ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 11059ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 12060ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
>
>
>

-- 
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: make a struct pointer _not_ implement an interface

2016-09-12 Thread Tyler Compton
I don't believe this is possible. See the spec on method sets[1].

The excerpt I'm looking at:

> The method set of any other type T consists of all methods 
>  declared with receiver 
> type T. The method set of the corresponding pointer type 
>  *T is the set of all methods 
> declared with receiver *T or T (that is, it also contains the method set 
> of T).


Which leads me to believe that a pointer to a type always includes at least 
the methods of the original type.

1. https://golang.org/ref/spec#Method_sets

On Monday, September 12, 2016 at 2:20:46 PM UTC-7, Alex Flint wrote:
>
> Is it possible to have a struct that implements an interface, but have 
> pointers to the struct not implement the interface? The reason is that I 
> want to find all the places in our codebase that attempt to use a pointer 
> to a certain struct as a certain interface.
>

-- 
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: What lead to the versionning debate?

2016-07-28 Thread Tyler Compton
It's funny that you mention libraries using vendoring because that's been a 
big deal surrounding this topic.

https://groups.google.com/d/msg/golang-dev/4FfTBfN2YaI/WCza__MaCgAJ

On Thursday, July 28, 2016 at 4:15:06 PM UTC-7, Chad wrote:
>
> Actually, nevermind. I was thinking about libraries using vendoring. But 
> that's probably a misuse.
>
> On Friday, July 29, 2016 at 12:50:47 AM UTC+2, Chad wrote:
>>
>> So if we decided that vendoring always used HEAD, that would ideally 
>> force people to have stable APIs (plus, why vendor an unstable/ in-flight 
>> API anyway)
>>
>> Couldn't it enable a change of behaviour for go get when a vendor 
>> directory is detected and solve some of the issues related to type equality 
>> (by having a single pkg path for a vendored package) ?
>>
>>
>>
>> On Friday, July 29, 2016 at 12:14:02 AM UTC+2, Dave Cheney wrote:
>>>
>>> Yes, exactly. 
>>
>>

-- 
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] Best practice for sets in go?

2016-07-26 Thread Tyler Compton
In my opinion, struct{} should always be used for placeholders. I also use 
it when sending to a channel where the data itself doesn't matter. struct{} 
looks gross but it's very expressive in this case and I think most all Go 
programmers are familiar with its meaning.

map[string]bool suggests that the bool value has some kind of significance. 
Sure, the documentation you put in probably says otherwise, but the bool 
type is still unnecessary indirection.

This issue is made worse if one uses the if m[key] { ... } idiom for the 
reason that Sam Whited brought up. Plus, then the bool has a meaning, but 
it's only for the purpose of slightly shortening code instead of using a 
well-known Go pattern. Why bother making the meaning of the map more 
complicated?

if _, ok = m[key]; ok {
}

Is something Go programmers are used to.

if m[ok] {
}

Requires that the programmer take a look at the map and its documentation 
to see what's going on unless they're already used to that pattern in the 
code base.

On Tuesday, July 26, 2016 at 7:07:08 AM UTC-7, Sam Whited wrote:
>
> On Tue, Jul 26, 2016 at 6:35 AM, Dave Cheney  > wrote: 
> > If saving one byte per entry is important for your application, the 
> latter is your choice. The former has nicer properties that you can use the 
> single value form of map access, 
> > 
> > if m[key] { 
> >// found 
> > } 
> > 
> > I'd say the former is the right choice for 97.25% of general use cases. 
>
> I'd agree with this, except that I don't trust that one guy in the 
> office not to sneak past something that somehow puts a false in the 
> map and causes bugs later. Arguably that's a review problem, but even 
> so one or two extra bytes of code (`_, ok = m[key]; ok') seems like a 
> small price to pay for safety guarantees and to save a few bytes of 
> memory. 
>
> (though as you said, it hardly matters either way; I just prefer to 
> recommend the struct{} version to new people) 
>
> —Sam 
>
>
> -- 
> Sam Whited 
> pub 4096R/54083AE104EA7AD3 
>

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


  1   2   >