[go-nuts] Appengine and main package

[Sankar]

Hi

I am evaluating appengine for a golang project. It is a simple REST server 
with a bunch of endpoints. I am currently deploying it in AWS, in an EC2 
instance. I have written a systemd script file which will take care of 
launching the webserver as a systemd service (so that it is always up etc.).

I am evaluating appengine and I see that we need to change the package main 
to something else, as appengine needs to have its own main package. This is 
kind of annoying as now I cannot easily test in my dev laptop or have the 
same code across my EC2 instance and appengine. So, are there any tricks to 
switch the main package automatically when I am deploying to appengine ? 
(Some kind of pre-push patch or something ?)

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.

Re: [go-nuts] time.AddDate() odd behavior

[Lucio]

Ian is perfectly right.

Subtracting 31 days and then manually "normalising" to end-of-month would 
seem to give the result being sought here. The existing normalising rule 
makes perfect mathematical sense and slipping it this way or that on some 
spurious pretext will just confuse matters. Such adjustments ought to be 
explicit and clearly documented.

Lucio.

On Tuesday, 31 October 2017 22:32:47 UTC+2, Ian Lance Taylor wrote:
>
> On Tue, Oct 31, 2017 at 10:53 AM, Alex Dvoretskiy 
>  wrote: 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "time" 
> > ) 
> > 
> > func main() { 
> > t := time.Date(2009, time.December, 31, 23, 0, 0, 0, time.UTC) 
> > fmt.Println(t) 
> > fmt.Println(t.AddDate(0, -1, 0)) 
> > } 
> > 
> > https://play.golang.org/p/hZ7nhnkepK 
> > 
> > The result is 
> > 
> > 2009-12-31 23:00:00 + UTC 
> > 2009-12-01 23:00:00 + UTC 
> > 
> > 
> > I think it should be: 
> > 
> > 2009-12-31 23:00:00 + UTC 
> > 2009-11-30 23:00:00 + UTC 
> > 
> > 
> > Documentation states that "AddDate normalizes its result in the same way 
> > that Date does, so, for example, adding one month to October 31 yields 
> > December 1, the normalized form for November 31."  This is makes sense 
> when 
> > you work with time.Date() function, because hours and minutes involved, 
> time 
> > zones, daylight savings etc. 
> > 
> > But it doesn't make any sense If you operate with days, months, years 
> for 
> > analytical purposes. I think the normal practice ("Normalization") in 
> this 
> > case would be to add exactly one month just like in other languages. Not 
> one 
> > month and one day. 
>
> I think the function is behaving as documented.  You subtracted one 
> month from December 31, 2009, which gives you November 31, 2009.  We 
> must then normalize that in the same was as the Date function, which 
> gives you December 1, 2009, which is what you see.  I don't think we 
> can change this now, as it would break backward compatibility.  Even 
> if we were willing to change it, I don't actually understand what you 
> are proposing.  What rule tells us that one month before December 31 
> is November 30?  Or, what rule tells us to normalize November 31 to 
> November 30 rather than December 1? 
>
> 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] Re: Is the Go build for 1.9.2 (or maybe 1.4) meant to create $HOME/pprof/?

[mikioh . mikioh]

The details: https://go-review.googlesource.com/c/go/+/37652 and 
https://github.com/google/pprof/issues/107

-- 
You received this message because you are subscribed to the Google 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: Is the Go build for 1.9.2 (or maybe 1.4) meant to create $HOME/pprof/?

[Lucio]

On Wednesday, 1 November 2017 06:16:29 UTC+2, Lucio wrote:
>
> That's what I found (I was building as root, if that makes a difference), 
> but I was rather surprised to find a "pprof" when the only Go activity I 
> still recall from yesterday was a fresh Go build, first go1.4, then go1.9.2.
>
> Oh, I must add, this was on Linux (Debian Wheezy, my colleagues inform me):

Linux pontiff 3.2.0-4-amd64 #1 SMP Debian 3.2.93-1 x86_64 GNU/Linux

Lucio.

-- 
You received this message because you are subscribed to the Google 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] Is the Go build for 1.9.2 (or maybe 1.4) meant to create $HOME/pprof/?

[Lucio]

That's what I found (I was building as root, if that makes a difference), 
but I was rather surprised to find a "pprof" when the only Go activity I 
still recall from yesterday was a fresh Go build, first go1.4, then go1.9.2.

Lucio.

-- 
You received this message because you are subscribed to the Google 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] Boolean query string conversion into functional logic

[Hamish Ogilvy]

Hey Jose,

Yep, might be worth a look at: https://github.com/influxdata/influxql for a 
pretty advanced and open source version. Also look at Rob Pike's calculator 
talk: https://www.youtube.com/watch?v=PXoG0WX0r_E That helped me a lot. You 
basically need a tokeniser and you then scan the input into tokens and 
build a tree of functions to represent the input. 

It's really valuable to build your own from scratch if you can.

Best.

On Wednesday, 1 November 2017 03:50:10 UTC+11, jose wrote:
>
> Hi Hamish, 
>
> Any updates on how to tackle this problem with current Go tools ? 
>
> Is it useful to use some of the Go parse tools or AST ? 
>
> Thanks 
>
> On Sat, Feb 22, 2014 at 11:01 AM, Hamish Ogilvy  > wrote: 
> > Cool javascript, nice way to visualise! RPN was a useful tip, found one 
> > interesting one Go based: 
> > https://github.com/zephyrtronium/rpn 
> > 
> > Looks like i'll have to smash this out myself. Will post it once done. 
> > 
> > Thanks again! 
> > 
> > 
> > On 22 February 2014 20:11, egon  
> wrote: 
> >> 
> >> Essentially what you need to do is first tokenize the text and then 
> >> transform that to a hierarchy of expressions. 
> >> 
> >> Simplest way is to apply shunting yard algorithm and do the expression 
> >> evaluation with RPN. This works very well if you only have binary 
> operators. 
> >> 
> >> Alternatively you can use some sort of simple parser... one that I 
> >> experimented was was http://egonelbre.com/js/bigram/, and should suit 
> your 
> >> needs well enough (although it is written in javascript, it's fairly 
> short 
> >> and simple... but inefficient in speed). 
> >> 
> >> There's also possibility to use ragel with go to generate a state 
> machine 
> >> that builds the hierarchy. 
> >> 
> >> If you are not going to do very complex language, then yacc might be 
> >> overkill. 
> >> 
> >> egon 
> >> 
> >> -- 
> >> You received this message because you are subscribed to a topic in the 
> >> Google Groups "golang-nuts" group. 
> >> To unsubscribe from this topic, visit 
> >> https://groups.google.com/d/topic/golang-nuts/phpOipu03G0/unsubscribe. 
> >> To unsubscribe from this group and all its topics, send an email to 
> >> golang-nuts...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
> > -- 
> > You received this message because you are subscribed 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/groups/opt_out. 
>

-- 
You received this message because you are subscribed to the Google 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] time.AddDate() odd behavior

[John Souvestre]

> What rule tells us that one month before December 31 
is November 30?  Or, what rule tells us to normalize November 31 to 
November 30 rather than December 1?

 

End-of-month mode is needed pretty often, in my experience.  Perhaps there 
should be two rules so the user could choose which fits his situation?  The 
current method and a new method with a slightly different name, ex: AddEOM?

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Alex Dvoretskiy
Sent: 2017 October 31, Tue 16:20
To: golang-nuts
Subject: Re: [go-nuts] time.AddDate() odd behavior

 

Yes, there is no particular rule for this case. I guess it depends on the 
industry, department, or even particular individual. In finance, it would be 
normalized to November 30. In power engineering December 1. I'm not proposing. 
Just want to know other peoples opinions on this case for better Go 
understanding.

On Tuesday, October 31, 2017 at 1:32:47 PM UTC-7, Ian Lance Taylor wrote:

On Tue, Oct 31, 2017 at 10:53 AM, Alex Dvoretskiy 
 wrote: 
> 
> package main 
> 
> import ( 
> "fmt" 
> "time" 
> ) 
> 
> func main() { 
> t := time.Date(2009, time.December, 31, 23, 0, 0, 0, time.UTC) 
> fmt.Println(t) 
> fmt.Println(t.AddDate(0, -1, 0)) 
> } 
> 
> https://play.golang.org/p/hZ7nhnkepK 
> 
> The result is 
> 
> 2009-12-31 23:00:00 + UTC 
> 2009-12-01 23:00:00 + UTC 
> 
> 
> I think it should be: 
> 
> 2009-12-31 23:00:00 + UTC 
> 2009-11-30 23:00:00 + UTC 
> 
> 
> Documentation states that "AddDate normalizes its result in the same way 
> that Date does, so, for example, adding one month to October 31 yields 
> December 1, the normalized form for November 31."  This is makes sense when 
> you work with time.Date() function, because hours and minutes involved, time 
> zones, daylight savings etc. 
> 
> But it doesn't make any sense If you operate with days, months, years for 
> analytical purposes. I think the normal practice ("Normalization") in this 
> case would be to add exactly one month just like in other languages. Not one 
> month and one day. 

I think the function is behaving as documented.  You subtracted one 
month from December 31, 2009, which gives you November 31, 2009.  We 
must then normalize that in the same was as the Date function, which 
gives you December 1, 2009, which is what you see.  I don't think we 
can change this now, as it would break backward compatibility.  Even 
if we were willing to change it, I don't actually understand what you 
are proposing.  What rule tells us that one month before December 31 
is November 30?  Or, what rule tells us to normalize November 31 to 
November 30 rather than December 1? 

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: How to know if interface{} data is nil w/o reflecting?

[Jesse McNelis]

On Wed, Nov 1, 2017 at 3:42 AM,   wrote:
> Today you can't, Ayan.
>

It's very consistent, you can't compare an interface value reliably to
any untyped constant.
Because there is no way for the compiler to figure out what type it should take.

https://play.golang.org/p/4Fn0YNE2md

-- 
You received this message because you are subscribed to the Google 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: tls field in struct m

[melodyhuibo]

Thanks a lot!.
For amd64, it seems not call set_thread_area system call. so in amd 64, for 
tls, only useful information should be the tls[0] which points to current 
g, right?

Thanks
Melody


On Tuesday, October 31, 2017 at 12:01:40 PM UTC-7, melod...@gmail.com wrote:
>
> Hi All,
>
> I have one question about tls field in the m struct. 
>
> I see fs:0FFF8h is storing the pointer to current g which is 
> the first element in tls field.
>
> In the m struct. tls is an six elements pointer array. I see the last five 
> has 0 value in it. I wonder what are these 5 elements storing as design?
>
>
> Thanks
> Melody
>

-- 
You received this message because you are subscribed to the Google 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] time.AddDate() odd behavior

[Alex Dvoretskiy]

Yes, there is no particular rule for this case. I guess it depends on the 
industry, department, or even particular individual. In finance, it would 
be normalized to November 30. In power engineering December 1. I'm not 
proposing. Just want to know other peoples opinions on this case for better 
Go understanding.

On Tuesday, October 31, 2017 at 1:32:47 PM UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Oct 31, 2017 at 10:53 AM, Alex Dvoretskiy 
>  wrote: 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "time" 
> > ) 
> > 
> > func main() { 
> > t := time.Date(2009, time.December, 31, 23, 0, 0, 0, time.UTC) 
> > fmt.Println(t) 
> > fmt.Println(t.AddDate(0, -1, 0)) 
> > } 
> > 
> > https://play.golang.org/p/hZ7nhnkepK 
> > 
> > The result is 
> > 
> > 2009-12-31 23:00:00 + UTC 
> > 2009-12-01 23:00:00 + UTC 
> > 
> > 
> > I think it should be: 
> > 
> > 2009-12-31 23:00:00 + UTC 
> > 2009-11-30 23:00:00 + UTC 
> > 
> > 
> > Documentation states that "AddDate normalizes its result in the same way 
> > that Date does, so, for example, adding one month to October 31 yields 
> > December 1, the normalized form for November 31."  This is makes sense 
> when 
> > you work with time.Date() function, because hours and minutes involved, 
> time 
> > zones, daylight savings etc. 
> > 
> > But it doesn't make any sense If you operate with days, months, years 
> for 
> > analytical purposes. I think the normal practice ("Normalization") in 
> this 
> > case would be to add exactly one month just like in other languages. Not 
> one 
> > month and one day. 
>
> I think the function is behaving as documented.  You subtracted one 
> month from December 31, 2009, which gives you November 31, 2009.  We 
> must then normalize that in the same was as the Date function, which 
> gives you December 1, 2009, which is what you see.  I don't think we 
> can change this now, as it would break backward compatibility.  Even 
> if we were willing to change it, I don't actually understand what you 
> are proposing.  What rule tells us that one month before December 31 
> is November 30?  Or, what rule tells us to normalize November 31 to 
> November 30 rather than December 1? 
>
> 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.

Re: [go-nuts] tls field in struct m

[Ian Lance Taylor]

On Tue, Oct 31, 2017 at 11:43 AM,   wrote:
>
> I have one question about tls field in the m struct.
>
> I see fs:0FFF8h is storing the pointer to current g which is the
> first element in tls field.
>
> In the m struct. tls is an six elements pointer array. I see the last five
> has 0 value in it. I wonder what are these 5 elements storing as design?

This is driven mainly by 386 GNU/Linux, on which we pass the address
of the m's tls field to the set_thread_area system call.  We the %gs
segment selector to point to >tls[4], and then we want to make
system calls via 0x10(%gs), or at least we used to before
https://golang.org/issue/14476.  The dynamic linker stores the vdso
helper at 0x10(%gs), so we need to set the length of the tls array to
6 to make sure there is room for that.  But I don't recall why we set
the segment selector to the address of the 4th element.  It may have
something to do with Darwin.

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] tls field in struct m

[melodyhuibo]

Hi All,

I have one question about tls field in the m struct. 

I see fs:0FFF8h is storing the pointer to current g which is 
the first element in tls field.

In the m struct. tls is an six elements pointer array. I see the last five 
has 0 value in it. I wonder what are these 5 elements storing as design?


Thanks
Melody

-- 
You received this message because you are subscribed to the Google 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 vendoring question

[Shawn Milochik]

I'd just "vendor" it manually.

Copy it into your vendor folder, and change its internal imports (if
necessary) to remove the external (github) references, and update your own
code to refer to "package" instead of "github.com/user/package."

-- 
You received this message because you are subscribed to the Google 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] Go vendoring question

[Travis Keep]

Somebody I depend on for my project made a breaking change to their git 
repo and broke my build.

I found that if I simply revert their latest commit locally that my project 
builds.  

I don't necessarily want to vendor everything because most of the libraries 
I use I trust. But I do want to vendor the one git repo whose owner keeps 
making breaking changes. 

I looked at dep, but dep seems to vendor everything. I don't want that. I 
just want to vendor the one unstable library, and simply use HEAD for 
everything else.

What is the best way for me to proceed?  

Thanks in advance,



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] time.AddDate() odd behavior

[Alex Dvoretskiy]

Hello Golang-nuts,

*package main*

*import (*
* "fmt"*
* "time"*
*)*

*func main() {*
* t := time.Date(2009, time.December, 31, 23, 0, 0, 0, time.UTC)*
* fmt.Println(t)*
* fmt.Println(t.AddDate(0, -1, 0))*
*}*

https://play.golang.org/p/hZ7nhnkepK

The result is

2009-12-31 23:00:00 + UTC
2009-12-01 23:00:00 + UTC


I think it should be:

2009-12-31 23:00:00 + UTC
2009-11-30 23:00:00 + UTC


Documentation states that "AddDate normalizes its result in the same way that 
Date does, so, for example, adding one month to October 31 yields December 1, 
the normalized form for November 31."  This is makes sense when you work with 
time.Date() function, because hours and minutes involved, time zones, daylight 
savings etc. 

But it doesn't make any sense If you operate with days, months, years for 
analytical purposes. I think the normal practice ("Normalization") in this case 
would be to add exactly one month just like in other languages. Not one month 
and one day. SQL for example:


DECLARE @sp_Date DATETIME = '2009-12-31'

SELECT @sp_Date

SELECT DATEADD(mm , -1, @sp_Date)


2009-12-31 00:00:00.000

2009-11-30 00:00:00.000

-- 
You received this message because you are subscribed to the Google 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 know if interface{} data is nil w/o reflecting?

['Axel Wagner' via golang-nuts]

On Tue, Oct 31, 2017 at 5:33 PM,  wrote:

> The internal layout Go uses to store an interface should not mess with the
> expected behavior.
>
If interface is two separate fields, or just a pointer, or refers to a
> bitmap stored on the Moon, I don't care. I shouldn't care.


And you don't have to care. This is not an implementation detail, it is a
spec-detail. It is a consequence of

a) Methods can be declared on any type, including pointers
b) Methods can be called on any value of that type, including its zero value
c) An interface is a type for "any type with the following sets of methods"

Whether you represent an interface as one word, two words, zero words or
one billion words is irrelevant, as long as you implement Go, you have to
adhere to these rules and they imply the criticized behavior. Personally, I
have a gripe with the fact that the FAQ justifies this behavior with an
implementation detail, when really it's a consequence of the language. The
rules a), b) and c) make individually total sense. It makes sense to be
able to declare methods on pointers, as it is expected that methods can
modify state from other imperative languages. It makes sense that methods
can be called on zero values, because they should be a property of the
type, not the value. It makes sense to have the notion of a method set as
an interface.

I sincerely hope Go 2 will have it fixed.
>

https://github.com/golang/go/issues/21538 has already been filed and there
might be other issues amounting to the same thing. I think it is fair to
say, that a) for Go1, this can't be changed either way and b) for Go2, the
community is aware of the confusion.

-- 
You received this message because you are subscribed to the Google 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] Boolean query string conversion into functional logic

[Jose]

Hi Hamish,

Any updates on how to tackle this problem with current Go tools ?

Is it useful to use some of the Go parse tools or AST ?

Thanks

On Sat, Feb 22, 2014 at 11:01 AM, Hamish Ogilvy  wrote:
> Cool javascript, nice way to visualise! RPN was a useful tip, found one
> interesting one Go based:
> https://github.com/zephyrtronium/rpn
>
> Looks like i'll have to smash this out myself. Will post it once done.
>
> Thanks again!
>
>
> On 22 February 2014 20:11, egon  wrote:
>>
>> Essentially what you need to do is first tokenize the text and then
>> transform that to a hierarchy of expressions.
>>
>> Simplest way is to apply shunting yard algorithm and do the expression
>> evaluation with RPN. This works very well if you only have binary operators.
>>
>> Alternatively you can use some sort of simple parser... one that I
>> experimented was was http://egonelbre.com/js/bigram/, and should suit your
>> needs well enough (although it is written in javascript, it's fairly short
>> and simple... but inefficient in speed).
>>
>> There's also possibility to use ragel with go to generate a state machine
>> that builds the hierarchy.
>>
>> If you are not going to do very complex language, then yacc might be
>> overkill.
>>
>> egon
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/phpOipu03G0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google 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/groups/opt_out.

-- 
You received this message because you are subscribed to the Google 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 know if interface{} data is nil w/o reflecting?

[Marvin Renich]

* oju...@gmail.com  [171031 12:34]:
> Ian, with all due respect, I beg to differ.
> 
> Let's look at that example posted 5 years back:
> 
> http://play.golang.org/p/Isoo0CcAvr
> 
> Yes, that is the proper behavior according to the rules, we have a FAQ 
> entry, fine, but ... put simply: that makes no sense. Why? Because we, the 
> users, expect the code to work the other way. That is a big surprise and we 
> don't need the tool creating surprises for us, much to the contrary.

I beg to differ.  I, a user, very much expect the current behavior and
would be very surprised if it worked the way you are suggesting.

Ian's msg gives good reasons why it would be wrong to change the
behavior, even if we could go back in time to before the release of Go
1 and the Compatibility Guarantee.

...Marvin

-- 
You received this message because you are subscribed to the Google 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 know if interface{} data is nil w/o reflecting?

[ojucie]

Ian, with all due respect, I beg to differ.

Let's look at that example posted 5 years back:

http://play.golang.org/p/Isoo0CcAvr

Yes, that is the proper behavior according to the rules, we have a FAQ 
entry, fine, but ... put simply: that makes no sense. Why? Because we, the 
users, expect the code to work the other way. That is a big surprise and we 
don't need the tool creating surprises for us, much to the contrary.

The internal layout Go uses to store an interface should not mess with the 
expected behavior. If interface is two separate fields, or just a pointer, 
or refers to a bitmap stored on the Moon, I don't care. I shouldn't care. 
The fact that today we must tell every new Go user this whole story is a 
shame. Go is meant to be easy, after all.

The behavior of a software of mine is not what my user expect? In my book 
that means I have a bug. Even with a very reasonable explanation, that 
remains a bug. I can spend hours explaining a strange behavior to my user. 
He will tell me: "Oh, yes. Now I got it, thanks. Fix that".

That reminds me of an old adage:
“If the map doesn't agree with the ground the map is wrong” 
I sincerely hope Go 2 will have it fixed.

-- 
You received this message because you are subscribed to the Google 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] How to use HTTP proxy with net.Dial on TCP network?

[Christian LeMoussel]

I use net.DialTimeou to connects to endpoint address on "tcp" network

conn, err := net.DialTimeout("tcp", endpoint, connectionTimeout)
if err != nil {
return nil, err
}


Is it possible to use HTTP proxy (http://111.222.333.444:3128) with net.Dial 
on TCP network? 
How can I do this?

Thank for your help.





-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go/types#Check is not resolving external package source positions.

[adonovan via golang-nuts]

Glad you got things working. A few quick remarks:

1) You don't need to call ParseDir or CreateFromFiles. The loader will 
figure out what files you need to load for each package; just call 
config.Import(packagename).

2) The go/types tutorial says that export data doesn't contain position 
information. That used to be true, but we have since extended the export 
data format to include it.  I'll update it.

3) That said, I did once notice a bug whereby the position of the package 
declaration was reported instead of the correct location. If you are able 
to reproduce that bug, please report it.

cheers
alan

 

> On Sun, Oct 29, 2017 at 5:00 PM, Keynan Pratt  > wrote:
>
>> Can confirm the following works as expected:
>>
>>
>> package main
>>
>> import (
>> "fmt"
>> "go/parser"
>> "go/token"
>> "go/ast"
>> sourceLoader "golang.org/x/tools/go/loader"
>> )
>>
>> func main() {
>> pkgPath := "bitbucket.org/.../test_package"
>> dir := "../..//test_package"
>>
>> fset := token.NewFileSet()
>> packages, err := parser.ParseDir(fset, dir, nil, parser.AllErrors)
>> if err != nil {
>> fmt.Println(err)
>> return
>> }
>>
>> for _, p := range packages {
>> files := make([]*ast.File, 0, 8)
>> for _, file := range p.Files {
>> files = append(files, file)
>> }
>>
>> loader := sourceLoader.Config{Fset: fset}
>> loader.CreateFromFiles(pkgPath, files...)
>> prgm, err := loader.Load()
>> if err != nil {
>> fmt.Errorf(err.Error())
>> }
>>
>> info := prgm.Created[0].Info
>> fmt.Println("\tUsages from ", pkgPath)
>> for use := range info.Uses {
>> obj := info.Uses[use]
>>
>> pkgOfUse := obj.Pkg()
>> nameOfUse := obj.Name()
>> declPos := prgm.Fset.Position(obj.Pos())
>> if pkgOfUse == nil {
>>
>> fmt.Println("Package was nil for obj.id [ ", obj.Id(), " ]")
>> continue
>> }
>> fmt.Printf(
>> "\tUsage of %s # %s declared at %s:%d:%d\n",
>> pkgOfUse.Path(),
>> nameOfUse,
>> declPos.Filename, declPos.Line, declPos.Column)
>> }
>> }
>> }
>>
>>
 

-- 
You received this message because you are subscribed to the Google 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 know if interface{} data is nil w/o reflecting?

[Ayan George]

On 10/31/2017 10:25 AM, oju...@gmail.com wrote:
> Not being able to test for a nil interface is a Go language bug.
> 

Just curious:  How would you do this without type assertion or reflection?

-- 
You received this message because you are subscribed to the Google 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] Is there a best way to use a global httpclient but with a different timeout setting per request?

[mupenghaha]

Is there a way to add a timeout setting for per request if i declare a 
global var? Because in my case i need different timeout setting for per 
request.Currently i am doing it with creating a new client object for per 
request:

func getTiemoutClient(timeout int) *http.Client {
 client := {
Timeout: time.Duration(timeout) * time.Millisecond,
}
return client
}


is this a better way ?

func Do(ctx context.Context, client *http.Client, req *http.Request) 
(*http.Response, error) {
if client == nil {
client = http.DefaultClient
}
resp, err := client.Do(req.WithContext(ctx))
// If we got an error, and the context has been canceled,
// the context's error is probably more useful.
if err != nil {
select {
case <-ctx.Done():
err = ctx.Err()
default:
}
}
return resp, 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.

[go-nuts] Re: Why cmd/compile/internal/syntax is not using go/ast ?

[Dave Cheney]

None that I know about, changing the go/ast parser would be very difficult 
given the Go 1 guarantee.

On Tuesday, 31 October 2017 21:32:03 UTC+11, Abyx wrote:
>
> Are there plans on merging those two parsers?
>
> On Monday, October 30, 2017 at 10:12:18 PM UTC+3, Dave Cheney wrote:
>>
>> The short version is the former was written before the Go compiler was 
>> ported to Go.
>>
>> The longer story is laid out in this presentation from 2014. 
>> https://www.youtube.com/watch?v=QIE5nV5fDwA
>>
>> On Tuesday, 31 October 2017 04:30:06 UTC+11, Abyx wrote:
>>>
>>> Golang has two parsers. go/* for "go fmt", and 
>>> cmd/compile/internal/syntax for "go compile".
>>> Why is that?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why cmd/compile/internal/syntax is not using go/ast ?

[Abyx]

Are there plans on merging those two parsers?

On Monday, October 30, 2017 at 10:12:18 PM UTC+3, Dave Cheney wrote:
>
> The short version is the former was written before the Go compiler was 
> ported to Go.
>
> The longer story is laid out in this presentation from 2014. 
> https://www.youtube.com/watch?v=QIE5nV5fDwA
>
> On Tuesday, 31 October 2017 04:30:06 UTC+11, Abyx wrote:
>>
>> Golang has two parsers. go/* for "go fmt", and 
>> cmd/compile/internal/syntax for "go compile".
>> Why is that?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.