[go-nuts] URL handling

[Michael Jones]

Why doesn’t url.PathEscape convert a $ to a %24?

Looking at HTML specs that’s what seems should happen.

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

[go-nuts] Re: First time building a rest-api-based web app: general security-related questions

[Pat Farrell]

The first answer depends on more questions to language independent 
requirements  such as:
1) are you using TLS/HTTPS for first tier traffic protection?
2) what threat model do you have (what threats do you worry about? what do 
you deliberately ignore? Who are the bad guys?
3) How valuable is the information you are sending, retrieving, etc.?)
4) how much do you trust the remote client?
5) how paranoid are you?
6) do you trust some third party middleware?

-- 
You received this message because you are subscribed to the Google 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] First time building a rest-api-based web app: general security-related questions

[ofbizfanster]

i come from a java and c# background, and have built webapps the "classic" 
way (i.e., jsp, asp.net, cookies, server-side rendering, occasionally ajax, 
etc)

i am about to build my first (eventually) medium-sized web app, where the 
server-side would just be serving up data rest-api style, and both local 
and remote users would be connecting via a browser and/or a non-browser.

the webapp is meant for use within an organization only, but because the 
organization is spread out in three different locations, the rest api (or 
perhaps some sort of an api gateway?) would have to be exposed to the 
internet.

my questions are all security-related and we're thinking of using go as the 
programming language, and some external libraries such as routers (we're 
currently investigating gorilla mux, ozzo-routing, and others) etc.

(1) is validating JWTs in a web request's authorization header the current 
dominant best practice for securing an api? what are its pro's and con's? 

(2) would using a session cookie  + some authorization middleware (such as 
casbin) make sense for our situation? what are its pro's and con's?

thanks for helping!

-- 
You received this message because you are subscribed to the Google 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] get_tls macro and friends

[Rob Pike]

If you run go build with the -work flag, you can see the directory in which
the build happens, and go_asm is written there.

-rob


On Thu, Jan 25, 2018 at 2:25 PM, Caleb Spare  wrote:

> Quick question about the Go assembler.
>
> I'm trying to use the get_tls and related macros mentioned near the
> bottom of https://golang.org/doc/asm.
>
> Although the line
>
> # include "go_asm.h"
>
> doesn't give an error, subsequent lines where I use the macro fail:
>
> get_tls(CX) // unrecognized instruction "get_tls"
>
> The go_asm.h header seems to be generated by the toolchain rather than
> being a file I can take a look at. Does anyone know more about how it
> works? Is it only available to runtime code (though that's not
> mentioned on https://golang.org/doc/asm)?
>
> Thanks!
> Caleb
>
> --
> You received this message because you are subscribed to the Google 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] syscall.SetNonblock stopped working in Go 1.9.3

[Dave Keck]

Hey all, this program exits (as expected) when run with macOS 10.12.6 + Go
1.8.6, but it deadlocks when run with Go 1.9.3:

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

The same behavior is observed when using unix.SetNonblock instead of
syscall.SetNonblock.

It appears that the SetNonblock() functions don't have an effect in Go
1.9.3. Is this a known issue?

Thanks!
David

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

[go-nuts] get_tls macro and friends

[Caleb Spare]

Quick question about the Go assembler.

I'm trying to use the get_tls and related macros mentioned near the
bottom of https://golang.org/doc/asm.

Although the line

# include "go_asm.h"

doesn't give an error, subsequent lines where I use the macro fail:

get_tls(CX) // unrecognized instruction "get_tls"

The go_asm.h header seems to be generated by the toolchain rather than
being a file I can take a look at. Does anyone know more about how it
works? Is it only available to runtime code (though that's not
mentioned on https://golang.org/doc/asm)?

Thanks!
Caleb

-- 
You received this message because you are subscribed to the Google 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: Ensuring resource cleanup when app is killed

[Sundar Nadathur]

Thank you! Got it.

Regards,
Sundar

On Wednesday, January 24, 2018 at 3:23:04 PM UTC-8, Matt Harden wrote:
>
> When the program exits, all goroutines die instantly. The doc is saying 
> that the program does not wait for any goroutine to complete except the 
> "main" goroutine (the one that invoked the function main at startup). If 
> you do want to wait for other goroutines to exit before exiting the 
> program, which is often something you do want, that can be done using 
> sync.WaitGroup or other synchronization tools like channels. In the case of 
> Tamas's goroutine, nothing in main waits for it, assuming the program isn't 
> sent an interrupt signal, so the goroutine never "completes". It does 
> "exit" though, because all goroutines are part of the program, and when the 
> program exits, it exits entirely. Any goroutine that was running as part of 
> the program isn't running anymore, and in fact doesn't even "exist" in any 
> meaningful sense anymore.
>
> You are correct that contexts can be used to inform goroutines when to 
> perform cleanup steps and/or exit cleanly, but if you want to ensure that 
> the cleanup actually completes, you need to wait for the goroutine to 
> finish before returning from main (or running os.Exit, log.Fatal, panicking 
> without recovering, etc.). Otherwise the goroutine may abruptly stop 
> running at any time as the program exits.
>
> I hope that helps to clarify the documentation for you.
>
> On Wed, Jan 24, 2018 at 11:03 PM Sundar Nadathur  > wrote:
>
>> I am probably mis-understanding or missing something. The golang spec 
>>  says:
>> Program execution begins by initializing the main package and then 
>> invoking the function main. When that function invocation returns, the 
>> program exits. *It does not wait for other (non-main) goroutines to 
>> complete*.
>>
>> I gather that the context mechanism addresses this issue, by requiring 
>> every relevant go routine to get a context as a parameter and to check for 
>> ctx.Done channel. Since calling cancel() would send a message through that 
>> channel, every goroutine that is designed to listen on that channel would 
>> 'get the message' and can do their own cleanup/exit.
>>
>> However, this specific goroutine does not receive the context. The golang 
>> spec seems to say that it is not guaranteed to exit when the app dies or 
>> exits. Please clarify.
>>
>> Regards,
>> Sundar
>>
>>
>> On Wednesday, January 24, 2018 at 12:05:35 PM UTC-8, Tamás Gulácsi wrote:
>>>
>>> if the main goroutine exits, all other goroutines exit, too.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[go-nuts] Re: Gorilla Sessions Example Question

[aikiav8r]

Thanks - apparently I wasnt quite getting the -I argument correct with 
logout to make all of it work.  
I still have a little confusion about why the contents of the old cookie 
were not invalidated, to keep a newbie from doing stupid things like I was 
trying.

Thanks again !
-Lynch

>
>>

-- 
You received this message because you are subscribed to the Google 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: golang with single-page HTML.

[Glen Newton]

Try https://github.com/icza/gowut

https://gowut-demo.herokuapp.com/show

Glen

On Wednesday, January 24, 2018 at 4:24:51 PM UTC-5, matthe...@gmail.com 
wrote:
>
> One way is the server still serves all of those endpoints, but instead of 
> returning a full HTML page they each just return data. The single page 
> state depends on what data is received when each is queried. Using a 
> template for the single page is a way to set an initial state.
>
> jQuery has easy to use AJAX functions (GET with arguments encoded into the 
> URL and POST with arguments as part of the request body). Websockets are 
> another way to pass data.
>
> This pattern in the regular Go http handlers goes far with a JavaScript 
> client:
>
> js, err := json.Marshal(output)
> if err != nil {
> panic(err.Error())
> }
> w.Header().Set("Content-Type", "application/json")
> w.Write(js)
>
> Matt
>
> On Tuesday, January 23, 2018 at 8:13:06 PM UTC-6, jacktee...@gmail.com 
> wrote:
>>
>> i have a few .go programs that use the old /, /index, /about, /login, 
>> /signup etc. I have been trying to use the SPA single-page HTML. But I 
>> cannot figure out how to use SPA with my golang modules. Anyone have any 
>> simple examples of this? If I had my druthers, I would try use angular5 for 
>> screen handling, but AJAX is fine if someone has an example. 
>> New to the group. Thanks in advance for any advice or 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] Re: Web Framework for Beginners

[Glen Newton]

I am not going to be popular expressing this, but I really really really 
like gowut: https://github.com/icza/gowut

Just write (drop-dead simple) Go code for SPA, AJAX handled transparently, 
no fiddling with Javascript.

See: Gowut - Showcase of Features  
https://gowut-demo.herokuapp.com/show

Downside: all client events roundtrip to server.


Glen

On Wednesday, January 24, 2018 at 6:01:06 PM UTC-5, Michael Masouras wrote:
>
> I second what Shawn said, I just use the standard library. Whenever I need 
> something not quite covered (or an easier abstraction), I use gorilla 
> .t goi
>
> On Wed, Jan 24, 2018 at 6:16 AM, dc0d  > wrote:
>
>> gobuffalo  has a nice workflow (I've used it for 
>> two in-house apps).
>>
>>
>> On Wednesday, January 24, 2018 at 5:20:05 PM UTC+3:30, pradam wrote:
>>>
>>> Hi Gophers,
>>>
>>> As for Newbie to Go.I am excited to learn a *web framework* but I 
>>> don't know where to start please help me out by suggesting a good framework 
>>> for beginners.
>>>
>>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[go-nuts] Re: resource cleanup in closure

['simon place' via golang-nuts]

thanks for the interest, a Done method would be what i was thinking of by 
the type/object way to do it, rather than the closure way of 
handing-back/defering a func.

but its the isolation i'm thinking about, without some way to get the 
garbage collector to call code,( like in the original post using a defer 
effectively would have to have been doing, which seemed to me to be nice 
and neat ), you always end up polluting the calling code.

when using an unoptimised version, or optimised one way, you would 
generally need modification to the calling code to be able to switch to 
some other way, leaking the solution. unless, that is, you always call a 
Done/destructor from the calling code, and have a dummy method on the 
unoptimised version, which seems to be the best you can achieve. i guess 
this at least would be performant, given the compiler should short-cut such 
a call.

but for now i'm looking at other, non-registry ideas, but it seems to me 
this is fundamentally not optimal.

BTW i went with the closure solution simply based on the inability to store 
functions, matches the transitory nature of a global 
state/history/environment based optimisation. also i think these are the 
types of optimisation to be thinking about because they aren't going to 
matched by any compiler.

-- 
You received this message because you are subscribed to the Google 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: Ensuring resource cleanup when app is killed

[Matt Harden]

When the program exits, all goroutines die instantly. The doc is saying
that the program does not wait for any goroutine to complete except the
"main" goroutine (the one that invoked the function main at startup). If
you do want to wait for other goroutines to exit before exiting the
program, which is often something you do want, that can be done using
sync.WaitGroup or other synchronization tools like channels. In the case of
Tamas's goroutine, nothing in main waits for it, assuming the program isn't
sent an interrupt signal, so the goroutine never "completes". It does
"exit" though, because all goroutines are part of the program, and when the
program exits, it exits entirely. Any goroutine that was running as part of
the program isn't running anymore, and in fact doesn't even "exist" in any
meaningful sense anymore.

You are correct that contexts can be used to inform goroutines when to
perform cleanup steps and/or exit cleanly, but if you want to ensure that
the cleanup actually completes, you need to wait for the goroutine to
finish before returning from main (or running os.Exit, log.Fatal, panicking
without recovering, etc.). Otherwise the goroutine may abruptly stop
running at any time as the program exits.

I hope that helps to clarify the documentation for you.

On Wed, Jan 24, 2018 at 11:03 PM Sundar Nadathur 
wrote:

> I am probably mis-understanding or missing something. The golang spec
>  says:
> Program execution begins by initializing the main package and then
> invoking the function main. When that function invocation returns, the
> program exits. *It does not wait for other (non-main) goroutines to
> complete*.
>
> I gather that the context mechanism addresses this issue, by requiring
> every relevant go routine to get a context as a parameter and to check for
> ctx.Done channel. Since calling cancel() would send a message through that
> channel, every goroutine that is designed to listen on that channel would
> 'get the message' and can do their own cleanup/exit.
>
> However, this specific goroutine does not receive the context. The golang
> spec seems to say that it is not guaranteed to exit when the app dies or
> exits. Please clarify.
>
> Regards,
> Sundar
>
>
> On Wednesday, January 24, 2018 at 12:05:35 PM UTC-8, Tamás Gulácsi wrote:
>>
>> if the main goroutine exits, all other goroutines exit, too.
>
> --
> You received this message because you are subscribed to the Google 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: Web Framework for Beginners

[Michael Masouras]

I second what Shawn said, I just use the standard library. Whenever I need
something not quite covered (or an easier abstraction), I use gorilla
.

On Wed, Jan 24, 2018 at 6:16 AM, dc0d  wrote:

> gobuffalo  has a nice workflow (I've used it for
> two in-house apps).
>
>
> On Wednesday, January 24, 2018 at 5:20:05 PM UTC+3:30, pradam wrote:
>>
>> Hi Gophers,
>>
>> As for Newbie to Go.I am excited to learn a *web framework* but I
>> don't know where to start please help me out by suggesting a good framework
>> for beginners.
>>
>> 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.

[go-nuts] Re: Ensuring resource cleanup when app is killed

[Sundar Nadathur]

I am probably mis-understanding or missing something. The golang spec 
 says:
Program execution begins by initializing the main package and then 
invoking the function main. When that function invocation returns, the 
program exits. *It does not wait for other (non-main) goroutines to 
complete*.

I gather that the context mechanism addresses this issue, by requiring 
every relevant go routine to get a context as a parameter and to check for 
ctx.Done channel. Since calling cancel() would send a message through that 
channel, every goroutine that is designed to listen on that channel would 
'get the message' and can do their own cleanup/exit.

However, this specific goroutine does not receive the context. The golang 
spec seems to say that it is not guaranteed to exit when the app dies or 
exits. Please clarify.

Regards,
Sundar

On Wednesday, January 24, 2018 at 12:05:35 PM UTC-8, Tamás Gulácsi wrote:
>
> if the main goroutine exits, all other goroutines exit, too.

-- 
You received this message because you are subscribed to the Google 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: Graven: Build tool for Go projects.

[matthewjuran]

You are using interfaces to define a type. The overhead of interface isn’t 
necessary to achieve the same goal. I see that github.com/gorilla also uses 
this pattern in places. Supporting another tool or providing a mock for 
testing is just making a new value of the type.

I do use sub-packages and encapsulation to simplify working with certain 
concepts, but here my opinion is the use of encapsulation is not adding 
much value. My experience has been that Go utility functions are more 
easily copy-pasted into each project rather than shared, although for an 
ecosystem of applications I can see that shared packages would form. But 
for this project the effort seems too early. My opinion is make the package 
when you need it.

Matt

On Wednesday, January 24, 2018 at 10:06:17 AM UTC-6, Clinton Begin wrote:
>
>
> Hi Matt, thanks for the review.
>
> Here is some feedback and explanation.
>
> >> Does BuildTool need to be an interface? Having methods on a pointer to 
> nothing (type GoBuildTool struct{}) seems unnecessary to me.
>
> Interfaces are expressions of functional contract, and have little 
> dependency or basis for requiring state (fields on a struct). BuildTool is 
> an interface for two reasons. The first is that there is potential to 
> support other build tools other than the go executable. I briefly 
> considered supporting gb for example. But also, who knows. Someday maybe 
> there will be a gnu go compiler or some such thing. The second reason is 
> unit testing. While I don't mock that interface in any of the current unit 
> tests, this allows me to if I need to at some point. In some languages 
> performing an extract interface refactoring after the fact is easy. Golang 
> is not one of those languages. So erring slightly on the side of interfaces 
> is worth it, especially where there are clear cases for alternative 
> implementations or test isolation from external dependencies (both 
> applicable in this case). 
>
> >> Also, why not have this at the level of package main?
> >> Same with graven/commands, graven/config, graven/domain, graven/util, 
> since these are specific to 
> >> graven they could also be part of package main. Config is just defining 
> one type.
>
> As a practice I try to keep as much out of main as possible. Not only does 
> it keep code more organized as the project grows, as in any other language, 
> but in Go it also means that I can access this code as a library from other 
> potential tools or test harnesses. I don't let the number of files dictate 
> what should be a package or not. It's functional context that contributes 
> to that decision.
>
> >>  interface makes sense when just grouping behavior with no data 
> structure
>
> Again, interfaces have nothing to do with state or data. An interface is a 
> functional contract. It says: Any such thing that deems itself as 
> implementing an interface (implicit in Go), must implement these functions. 
> There is no reliance or direct relationship to state, either by design, 
> contract or even pattern. In fact, more often than not, interfaces describe 
> the core logic of a system or interfaces to external systems, and having 
> mutable state in such implementations leads to a source of bugs in the form 
> of shared state, race conditions and locking. For this reason, many 
> interfaces choose to accept their state as parameters to their functions, 
> rather than store them as part of the implementation.
>
> I recommend this blog post to learn more: 
> http://jordanorelli.com/post/32665860244/how-to-use-interfaces-in-go
>
> >> Well-named package main files and types provide just as good logical 
> separation.
>
> I disagree here. Golang has very weak encapsulation. There are very few 
> options for protecting access to fields and functions. Go only has package 
> level access rules, and therefore packages do a lot more for accessibility 
> than is necessary to consider in other languages. In C# or Java, sure, you 
> could put every file in one package or directory and protect access to 
> fields and functions. But you still wouldn't do that for the sake of code 
> organization and even in Java, scoping as well (protected is also package 
> scoped). So I disagree with your suggestion here in Go and any other 
> language really. 
>
> >> graven/resources/commmon is misspelled. I’m not sure why you have these 
> simple text files when a const in code
>
> Well that is embarrassing. :-) Those are old test fixtures that I don't 
> think are used anymore. I've since moved test fixtures to the test_fixtures 
> directory, but those seem to have been left behind. Thanks for catching 
> that.
>
> Cheers,
> Clinton
>
> On Sunday, January 21, 2018 at 9:36:57 AM UTC-7, matthe...@gmail.com 
> wrote:
>>
>> Hi Clinton, here’s a code review.
>>
>> Does BuildTool need to be an interface? Having methods on a pointer to 
>> nothing (type GoBuildTool struct{}) seems unnecessary to me. Also, why not 
>> have this at the level of package 

Re: [go-nuts] Re: Nil Channels and Case Evaluation

[roger peppe]

On 24 January 2018 at 20:58, Axel Wagner  wrote:
> On Wed, Jan 24, 2018 at 9:12 PM, roger peppe  wrote:
>>
>> Why? Consider this code. When c is first evaluated, it's ok to send
>> on, so it would
>> evaluate f, but f causes c to be not ready, so f has been evaluated even
>> though
>> c cannot be sent on.
>>
>> package main
>>
>> import (
>> "log"
>> "time"
>> )
>>
>> func main() {
>> c := make(chan int, 1)
>> f := func() int {
>> c <- 1
>> return 0
>> }
>> select {
>> case c <- f():
>> case <-time.After(time.Second):
>> log.Printf("could not send value")
>> }
>> }
>
>
> This is a pretty cool counter-example. You can even take it one step further
>
> c := make(chan int, 1)
> f := func() int {
> c = nil
> return 0
> }
> select {
> case c <- f():
> }
>
> whoops.

I'm not sure that's quite as good because the left side of the <- operator
must be evaluated before f() is evaluated, so by the time f is
invoked, the select already knows the channel (it must be able
to store the channel because the expression on the left may be a function call)

-- 
You received this message because you are subscribed to the Google 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: Nil Channels and Case Evaluation

[dc0d]

You are right Alex.

And seems I am wrong and it does not really matter that much and is not a 
fruitful topic.

-- 
You received this message because you are subscribed to the Google 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: golang with single-page HTML.

[matthewjuran]

One way is the server still serves all of those endpoints, but instead of 
returning a full HTML page they each just return data. The single page 
state depends on what data is received when each is queried. Using a 
template for the single page is a way to set an initial state.

jQuery has easy to use AJAX functions (GET with arguments encoded into the 
URL and POST with arguments as part of the request body). Websockets are 
another way to pass data.

This pattern in the regular Go http handlers goes far with a JavaScript 
client:

js, err := json.Marshal(output)
if err != nil {
panic(err.Error())
}
w.Header().Set("Content-Type", "application/json")
w.Write(js)

Matt

On Tuesday, January 23, 2018 at 8:13:06 PM UTC-6, jacktee...@gmail.com 
wrote:
>
> i have a few .go programs that use the old /, /index, /about, /login, 
> /signup etc. I have been trying to use the SPA single-page HTML. But I 
> cannot figure out how to use SPA with my golang modules. Anyone have any 
> simple examples of this? If I had my druthers, I would try use angular5 for 
> screen handling, but AJAX is fine if someone has an example. 
> New to the group. Thanks in advance for any advice or 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] Re: Nil Channels and Case Evaluation

['Axel Wagner' via golang-nuts]

On Wed, Jan 24, 2018 at 8:59 PM, dc0d  wrote:

> It is as described in the spec. Regarding the specs it's correct. But
> that's not the reason.
>

You didn't ask for a reason this time, you ask for what is happening.


> The original question is about the "why".
>
> Why is that so? This behavior was unexpected.
>

And it was explained to you, repeatedly. Maybe you could try and explain
why the explanations given to you aren't sufficient? Like, you got

* Evaluating the RHS only after the communication can succeed will forcibly
create an intolerable contention on the communication
* The evaluation order becomes predictable independently of the actual
value of the LHS
* It is easier to spec the evaluation order and the effect of sending on a
nil-channel separately, than mingling them
* Whatever, some decision had to be made, this seemed as good as any

and probably a couple' more at this point. In particular that first one
seems like very compelling reason not to do what you apparently expected.
At this point, you should explain a) why are these not enough and b) why
does it actually *matter*?
Like, say for the sake of argument that there literally was no reason.
Someone flipped a couple of coins and the current spec came out of those
coin flips. What does that change?


>
>
> On Wednesday, January 24, 2018 at 11:20:01 PM UTC+3:30, Axel Wagner wrote:
>>
>> Both the channel and the value expression are evaluated before
>>> communication begins. Communication blocks until the send can proceed. A
>>> send on an unbuffered channel can proceed if a receiver is ready. A send on
>>> a buffered channel can proceed if there is room in the buffer. A send on a
>>> closed channel proceeds by causing a run-time panic. A send on a nil
>>> channel blocks forever.
>>
>>
>> https://golang.org/ref/spec#Send_statements
>>
>> So, yes.
>>
>> On Wed, Jan 24, 2018 at 8:43 PM, dc0d  wrote:
>>
>>> If the channel is nil, there's nothing to lock. But also, there's no
 sending happening.

>>>
>>> So first the payload is computed and then the nil check happens?
>>>
>>> --
>>> You received this message because you are subscribed 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: Nil Channels and Case Evaluation

[roger peppe]

Why? Consider this code. When c is first evaluated, it's ok to send
on, so it would
evaluate f, but f causes c to be not ready, so f has been evaluated even though
c cannot be sent on.

package main

import (
"log"
"time"
)

func main() {
c := make(chan int, 1)
f := func() int {
c <- 1
return 0
}
select {
case c <- f():
case <-time.After(time.Second):
log.Printf("could not send value")
}
}

On 24 January 2018 at 19:59, dc0d  wrote:
> It is as described in the spec. Regarding the specs it's correct. But that's
> not the reason.
>
> The original question is about the "why".
>
> Why is that so? This behavior was unexpected.
>
> On Wednesday, January 24, 2018 at 11:20:01 PM UTC+3:30, Axel Wagner wrote:
>>>
>>> Both the channel and the value expression are evaluated before
>>> communication begins. Communication blocks until the send can proceed. A
>>> send on an unbuffered channel can proceed if a receiver is ready. A send on
>>> a buffered channel can proceed if there is room in the buffer. A send on a
>>> closed channel proceeds by causing a run-time panic. A send on a nil channel
>>> blocks forever.
>>
>>
>> https://golang.org/ref/spec#Send_statements
>>
>> So, yes.
>>
>> On Wed, Jan 24, 2018 at 8:43 PM, dc0d  wrote:

 If the channel is nil, there's nothing to lock. But also, there's no
 sending happening.
>>>
>>>
>>> So first the payload is computed and then the nil check happens?
>>>
>>> --
>>> You received this message because you are subscribed 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: Nil Channels and Case Evaluation

[Marvin Renich]

* dc0d  [180124 14:44]:
> 
> >
> > If the channel is nil, there's nothing to lock. But also, there's no 
> > sending happening.
> >
> 
> So first the payload is computed and then the nil check happens?

To add to what Axel said, it would be inconsistent to only evaluate the
LHS if the RHS was non-nil.  Just like in the select case.  Consider

foo_returns_channel() <- goo()

It should be determinable at the time the code is written (rather than
when it is executed) whether goo() will be evaluated or not.

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

[go-nuts] Re: Ensuring resource cleanup when app is killed

[Tamás Gulácsi]

if the main goroutine exits, all other goroutines exit, too.

-- 
You received this message because you are subscribed to the Google 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 pass Go []byte (arrays/slices) as C *char to C functions

['Bryan C. Mills' via golang-nuts]

On Wed, Jan 24, 2018 at 3:00 PM, Christian LeMoussel 
wrote:

> Thank you Bryan for your advice.
> In examples, I see how to pass the Go pointers directly.
>
> For example :
> h := C.CString(name)
> defer C.free(unsafe.Pointer(h))
> gerrno, err := C.getaddrinfo(h, nil, , )
> To
> h := make([]byte, len(name)+1)
> copy(h, name)
> gerrno, err := C.getaddrinfo((*C.char)(unsafe.Pointer([0])), nil,
> , )
>
> But I found nothing on how to append an extra 0 to the slice.
>

That's what the +1 in make([]byte, len(name)+1) does: it pads the buffer by
an extra byte, which make will initialize to 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: How to pass Go []byte (arrays/slices) as C *char to C functions

[Christian LeMoussel]

Thank you Bryan for your advice.
In examples, I see how to pass the Go pointers directly.

For example :
h := C.CString(name) 
defer C.free(unsafe.Pointer(h)) 
gerrno, err := C.getaddrinfo(h, nil, , )
To
h := make([]byte, len(name)+1)
copy(h, name)
gerrno, err := C.getaddrinfo((*C.char)(unsafe.Pointer([0])), nil, 
, )

But I found nothing on how to append an extra 0 to the slice.


-- 
You received this message because you are subscribed to the Google 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: Nil Channels and Case Evaluation

[dc0d]

It is as described in the spec. Regarding the specs it's correct. But 
that's not the reason. 

The original question is about the "why".

Why is that so? This behavior was unexpected.

On Wednesday, January 24, 2018 at 11:20:01 PM UTC+3:30, Axel Wagner wrote:
>
> Both the channel and the value expression are evaluated before 
>> communication begins. Communication blocks until the send can proceed. A 
>> send on an unbuffered channel can proceed if a receiver is ready. A send on 
>> a buffered channel can proceed if there is room in the buffer. A send on a 
>> closed channel proceeds by causing a run-time panic. A send on a nil 
>> channel blocks forever.
>
>
> https://golang.org/ref/spec#Send_statements
>
> So, yes.
>
> On Wed, Jan 24, 2018 at 8:43 PM, dc0d  > wrote:
>
>> If the channel is nil, there's nothing to lock. But also, there's no 
>>> sending happening.
>>>
>>
>> So first the payload is computed and then the nil check happens?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] Re: Nil Channels and Case Evaluation

['Axel Wagner' via golang-nuts]

>
> Both the channel and the value expression are evaluated before
> communication begins. Communication blocks until the send can proceed. A
> send on an unbuffered channel can proceed if a receiver is ready. A send on
> a buffered channel can proceed if there is room in the buffer. A send on a
> closed channel proceeds by causing a run-time panic. A send on a nil
> channel blocks forever.


https://golang.org/ref/spec#Send_statements

So, yes.

On Wed, Jan 24, 2018 at 8:43 PM, dc0d  wrote:

> If the channel is nil, there's nothing to lock. But also, there's no
>> sending happening.
>>
>
> So first the payload is computed and then the nil check happens?
>
> --
> You received this message because you are subscribed to the Google 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] Re: Flag package issue when nonflag argument string begins with a minus sign

[Scott Pakin]

On Wednesday, January 24, 2018 at 11:00:37 AM UTC-7, erisa wrote:
>
> I have a CLI program that uses the flag package and has one flag and takes 
> a string as its only nonflag argument.  The string can be a complex 
> expression, but it is possible that the first character of the string is a 
> minus sign.
> This parses correctly:
>
> powerseries -nterms=10 "x ^ 10"
>
> But this does not:
>
> powerseries -nterms=10 "-x ^ 10"
>
> It yields the error "flag provided but not defined: -x ^ 10".
>
> Is there a workaround for this problem?
>

Yes:

powerseries -nterms=10 -- "-x ^ 10"


The "--" means "end of flag arguments."

— Scott

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

Re: [go-nuts] Re: Nil Channels and Case Evaluation

[dc0d]

>
> If the channel is nil, there's nothing to lock. But also, there's no 
> sending happening.
>

So first the payload is computed and then the nil check happens?

-- 
You received this message because you are subscribed to the Google 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: Ensuring resource cleanup when app is killed

[Sundar Nadathur]

Thank you both for the replies. 

Hi Tamas, I am wondering about:
  go func() {
<-sigCh
cancel()
  }
If the program exits normally, presumably sigCh channel will not get 
notified, and this goroutine will continue to run. How do we ensure that it 
quits on normal program exit? 

Regards,
Sundar 

On Wednesday, January 24, 2018 at 6:08:25 AM UTC-8, Tamás Gulácsi wrote:
>
> func main() {
>   if err := Main(); err != nil {
> log.Fatal(err)
>   }
> }
>
> func Main() error {
>   ctx, cancel := cintext.WithCanvel(context.Background())
>   defer cancel()
>   sigCh := make(chan signal.Signal, 1)
>   go func() {
> <-sigCh
> cancel()
>   }
>   signal.Notify(sigCh, signal.Interrupt)
>
>   ...
>
>   return nil
> }
>
>

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

Re: [go-nuts] How to broadcast a graceful server shutdown down the road?

[Joris Berthelot]

Hi Justin,

Thank you for your answer. The thing is, from my understanding, the request 
context is done once the HTTP response has been returned so if my 
goroutines rely on this context, it's cancelled as soon as the response is 
sent. I would like my goroutines to be cancelled only when a graceful 
shutdown sign is intercepted by the server.

Or maybe I'm wrong but in this case, I would love to see a working example.

Thank you!


On Wednesday, January 24, 2018 at 7:33:02 PM UTC+1, Justin Israel wrote:
>
>
>
> On Thu, Jan 25, 2018, 4:50 AM Joris Berthelot  > wrote:
>
>> Hello everybody,
>>
>> First post in this group, I'm a bit new for the language (I've been more 
>> and less writing Go for a year now) and I have a question for you guys.
>>
>> I would like to know how to broadcast a HTTP server shutdown to any 
>> running goroutines launched by HTTP handlers. From what I understood, the 
>> common graceful shutdown uses a timed out context to gracefully close the 
>> active connections and block new incoming ones.
>>
>> Let's say I have a handler that returns a 202 response and launches 
>> several goroutines for mid-long running tasks. How, could I catch the 
>> graceful shutdown signal from main down deep the goroutines. 
>>
>> Like I said, I'm still a bit new and this is an architectural question 
>> I've been trying to solve for the past couple days, without success. I 
>> searched real quick in the group but I mostly found questions for graceful 
>> shutdown pre-Go 1.8.
>>
>
> The handler will be passed the request object, which provides access to a 
> context 
>
> https://godoc.org/net/http#Request.Context
>
> If you pass the context to your goroutines, then it is just a matter of 
> checking the Context for cancellation. When you use the shutdown feature of 
> the server, this will propagate 
>
> https://godoc.org/net/http#Server.Shutdown
>
>
>
>> Thank you very much,
>> -Joris
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[go-nuts] Flag package issue when nonflag argument string begins with a minus sign

[erisa]

I have a CLI program that uses the flag package and has one flag and takes 
a string as its only nonflag argument.  The string can be a complex 
expression, but it is possible that the first character of the string is a 
minus sign.
This parses correctly:

powerseries -nterms=10 "x ^ 10"

But this does not:

powerseries -nterms=10 "-x ^ 10"

It yields the error "flag provided but not defined: -x ^ 10".

Is there a workaround for this problem?

-- 
You received this message because you are subscribed to the Google 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: Nil Channels and Case Evaluation

['Axel Wagner' via golang-nuts]

If the channel is nil, there's nothing to lock. But also, there's no
sending happening.

But the conceptual locking Ian mentions is there no matter whether you a)
first compute the value and then wait to be able to send, or b) first wait
to be able to send and then compute the value. In both cases, you need to
lock the channel between deciding you can send and actually sending,
because otherwise, someone else might decide they can send too.
The difference is, that in a) this time-frame is much shorter than in b).

Also, FTR, I still believe it is unnecessarily complicated to talk about
select - exactly the same problems and things have to happen in a regular
send - if nothing else, then because you'll always want

ch <- expr

to behave the same way as

select {
case ch <- expr:
}

Talking about a normal send is conceptually simpler but the conclusions are
transferable between the two.

On Wed, Jan 24, 2018 at 5:03 PM, dc0d  wrote:

> Is this applied when the channel is nil? Does select statement first lock
> the channel then check if it's nil?
>
> On Wednesday, January 24, 2018 at 6:07:50 PM UTC+3:30, Ian Lance Taylor
> wrote:
>>
>> On Tue, Jan 23, 2018 at 10:13 PM, dc0d  wrote:
>> >
>> > The third option was the expected one. Locking aside (as the thought
>> line
>> > behind the original question), the time spent on preparing/calculating
>> a
>> > result value to be sent to a channel, is not directly relevant to the
>> case
>> > for nil channels - which were expected to get ignored. I do not
>> understand
>> > the internals of select statement and did not know it locks the
>> channel.
>>
>> Regardless of internal details, conceptually it has to lock the
>> channel.  The select statement has to atomically 1) decide that the
>> channel has room for a new value; 2) send the new value to the
>> channel.  There could be many goroutines sending to the channel
>> simultaneously.  If the select statement picks the channel first and
>> then computes the value to send, then it has to ensure that no other
>> goroutine can send to the channel while computing the value, as
>> otherwise once it has the value it might not be able to send it.
>>
>> 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 pass Go []byte (arrays/slices) as C *char to C functions

['Bryan Mills' via golang-nuts]

It may be considerably more efficient to pass the Go pointers directly.
To do so, you may need to convert through unsafe.Pointer.

Note that many C APIs that take a char* expect it to be null-terminated, so 
if you take that approach you may need to append an extra 0 to the slice.

https://golang.org/cl/56530 has some examples.


On Tuesday, January 23, 2018 at 11:31:44 AM UTC-5, Jan Mercl wrote:
>
> On Tue, Jan 23, 2018 at 5:02 PM Christian LeMoussel  > wrote:
>
> > Is it correct /best way ? 
>
> Hopefully/only. But as noted previously, not tested.
>   
> > There is no memory leaks ?
>
> Something must eventually C.free() the memory allocated by C.CString().
>
>
>
> -- 
>
> -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.

[go-nuts] Re: Graven: Build tool for Go projects.

[Clinton Begin]

Hi Matt, thanks for the review.

Here is some feedback and explanation.

>> Does BuildTool need to be an interface? Having methods on a pointer to 
nothing (type GoBuildTool struct{}) seems unnecessary to me.

Interfaces are expressions of functional contract, and have little 
dependency or basis for requiring state (fields on a struct). BuildTool is 
an interface for two reasons. The first is that there is potential to 
support other build tools other than the go executable. I briefly 
considered supporting gb for example. But also, who knows. Someday maybe 
there will be a gnu go compiler or some such thing. The second reason is 
unit testing. While I don't mock that interface in any of the current unit 
tests, this allows me to if I need to at some point. In some languages 
performing an extract interface refactoring after the fact is easy. Golang 
is not one of those languages. So erring slightly on the side of interfaces 
is worth it, especially where there are clear cases for alternative 
implementations or test isolation from external dependencies (both 
applicable in this case). 

>> Also, why not have this at the level of package main?
>> Same with graven/commands, graven/config, graven/domain, graven/util, 
since these are specific to 
>> graven they could also be part of package main. Config is just defining 
one type.

As a practice I try to keep as much out of main as possible. Not only does 
it keep code more organized as the project grows, as in any other language, 
but in Go it also means that I can access this code as a library from other 
potential tools or test harnesses. I don't let the number of files dictate 
what should be a package or not. It's functional context that contributes 
to that decision.

>>  interface makes sense when just grouping behavior with no data structure

Again, interfaces have nothing to do with state or data. An interface is a 
functional contract. It says: Any such thing that deems itself as 
implementing an interface (implicit in Go), must implement these functions. 
There is no reliance or direct relationship to state, either by design, 
contract or even pattern. In fact, more often than not, interfaces describe 
the core logic of a system or interfaces to external systems, and having 
mutable state in such implementations leads to a source of bugs in the form 
of shared state, race conditions and locking. For this reason, many 
interfaces choose to accept their state as parameters to their functions, 
rather than store them as part of the implementation.

I recommend this blog post to learn 
more: http://jordanorelli.com/post/32665860244/how-to-use-interfaces-in-go

>> Well-named package main files and types provide just as good logical 
separation.

I disagree here. Golang has very weak encapsulation. There are very few 
options for protecting access to fields and functions. Go only has package 
level access rules, and therefore packages do a lot more for accessibility 
than is necessary to consider in other languages. In C# or Java, sure, you 
could put every file in one package or directory and protect access to 
fields and functions. But you still wouldn't do that for the sake of code 
organization and even in Java, scoping as well (protected is also package 
scoped). So I disagree with your suggestion here in Go and any other 
language really. 

>> graven/resources/commmon is misspelled. I’m not sure why you have these 
simple text files when a const in code

Well that is embarrassing. :-) Those are old test fixtures that I don't 
think are used anymore. I've since moved test fixtures to the test_fixtures 
directory, but those seem to have been left behind. Thanks for catching 
that.

Cheers,
Clinton

On Sunday, January 21, 2018 at 9:36:57 AM UTC-7, matthe...@gmail.com wrote:
>
> Hi Clinton, here’s a code review.
>
> Does BuildTool need to be an interface? Having methods on a pointer to 
> nothing (type GoBuildTool struct{}) seems unnecessary to me. Also, why not 
> have this at the level of package main?
>
> Same with graven/commands, graven/config, graven/domain, graven/util, 
> since these are specific to graven they could also be part of package main. 
> Config is just defining one type.
>
> Since graven/domain.Project, Artifact, Repository, Version only has read 
> operations defined why not have the struct as method receiver instead of 
> pointer to the struct? I’d only move to the pointer for performance if 
> proven by a testing benchmark, pprof profile, and need, otherwise no 
> pointer is more understandable/readable.
>
> Again in graven/repotool, graven/vcstool, I’m not sure having an interface 
> makes sense when just grouping behavior with no data structure. Defining a 
> struct type with function fields with a var for docker, github, and maven 
> may be better. These packages are also application specific; packages 
> should be portable and not just used to group application logic. Well-named 
> package main files and types provide 

Re: [go-nuts] Re: Nil Channels and Case Evaluation

[dc0d]

Is this applied when the channel is nil? Does select statement first lock 
the channel then check if it's nil?

On Wednesday, January 24, 2018 at 6:07:50 PM UTC+3:30, Ian Lance Taylor 
wrote:
>
> On Tue, Jan 23, 2018 at 10:13 PM, dc0d  > wrote: 
> > 
> > The third option was the expected one. Locking aside (as the thought 
> line 
> > behind the original question), the time spent on preparing/calculating a 
> > result value to be sent to a channel, is not directly relevant to the 
> case 
> > for nil channels - which were expected to get ignored. I do not 
> understand 
> > the internals of select statement and did not know it locks the channel. 
>
> Regardless of internal details, conceptually it has to lock the 
> channel.  The select statement has to atomically 1) decide that the 
> channel has room for a new value; 2) send the new value to the 
> channel.  There could be many goroutines sending to the channel 
> simultaneously.  If the select statement picks the channel first and 
> then computes the value to send, then it has to ensure that no other 
> goroutine can send to the channel while computing the value, as 
> otherwise once it has the value it might not be able to send it. 
>
> 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] How to broadcast a graceful server shutdown down the road?

[Joris Berthelot]

Hello everybody,

First post in this group, I'm a bit new for the language (I've been more 
and less writing Go for a year now) and I have a question for you guys.

I would like to know how to broadcast a HTTP server shutdown to any running 
goroutines launched by HTTP handlers. From what I understood, the common 
graceful shutdown uses a timed out context to gracefully close the active 
connections and block new incoming ones.

Let's say I have a handler that returns a 202 response and launches several 
goroutines for mid-long running tasks. How, could I catch the graceful 
shutdown signal from main down deep the goroutines. 

Like I said, I'm still a bit new and this is an architectural question I've 
been trying to solve for the past couple days, without success. I searched 
real quick in the group but I mostly found questions for graceful shutdown 
pre-Go 1.8.

Thank you very much,
-Joris

-- 
You received this message because you are subscribed to the Google 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: Nil Channels and Case Evaluation

[Ian Lance Taylor]

On Tue, Jan 23, 2018 at 10:13 PM, dc0d  wrote:
>
> The third option was the expected one. Locking aside (as the thought line
> behind the original question), the time spent on preparing/calculating a
> result value to be sent to a channel, is not directly relevant to the case
> for nil channels - which were expected to get ignored. I do not understand
> the internals of select statement and did not know it locks the channel.

Regardless of internal details, conceptually it has to lock the
channel.  The select statement has to atomically 1) decide that the
channel has room for a new value; 2) send the new value to the
channel.  There could be many goroutines sending to the channel
simultaneously.  If the select statement picks the channel first and
then computes the value to send, then it has to ensure that no other
goroutine can send to the channel while computing the value, as
otherwise once it has the value it might not be able to send it.

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: "type MyByte byte", then how to convert []MyByte to []byte so that I can use bytes.Xyz functions for []MyByte?

[digg]

On Wednesday, January 24, 2018 at 8:35:25 AM UTC-5, Volker Dobler wrote:
>
> See https://golang.org/doc/faq#convert_slice_with_same_underlying_type
>
> On Wednesday, 24 January 2018 13:57:59 UTC+1, di...@veryhaha.com wrote:
>>
>> except unsafe ways.
>>
>
> Yes: explicit loop.
>
> Why did you do type MyByte byte in the first place?
> Extra methods on your byte?
>

I'm just studying the Go type system.
 

>
> V. 
>

-- 
You received this message because you are subscribed to the Google 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] Ensuring resource cleanup when app is killed

[Ian Lance Taylor]

On Tue, Jan 23, 2018 at 11:20 PM, Sundar Nadathur  wrote:
>
> My golang application creates UNIX sockets in specific paths:
> /mypath/name1.sock, /mypath/name2.sock etc. It then launches a go routine
> that listens to one or more of those sockets. I need to ensure that they get
> cleaned up (removed) at the end. I tried the obvious thing -- use defer in
> main() -- and eschewed the use of os.Exit() and log.Fatal(), since they
> don't ensure that defer statements are called.
>
> However, signals like ^C also apparently cause forced termination and don't
> run the defer statements. So, I have experimented with a signal handler
> registered from main(). However, it seems that the ^C is going to the go
> routine that is actually listening on the socket: I don't see the signal
> handler running.
>
> What is a good way to ensure that the resources are always cleaned up even
> in the presence of go routines and signals?

To handle a signal in a Go program, use the os/signal package.  I'm
not sure what you mean when you say that you registered a signal
handler.

That said, the only fully reliable way to do this is to use a separate
wrapper program.  The wrapper program will run the real program, and
then remove the sockets when the real program exits.  That is true in
any language.  There are too many different ways for a program to die,
and there is no way for a program in any language to reliably run code
as it is dying.

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] Web Framework for Beginners

[Shawn Milochik]

Don't use a framework. Use the standard library. It does everything you
need.

When you find something that you don't want to do "manually," go find a
package that you *plug into* your code.

When you start with a framework, you're accepting thousands of decisions
made by others. Many of them will make your life easier, and many more will
make your life much more difficult.

-- 
You received this message because you are subscribed to the Google 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: Web Framework for Beginners

[dc0d]

gobuffalo  has a nice workflow (I've used it for two 
in-house apps).

On Wednesday, January 24, 2018 at 5:20:05 PM UTC+3:30, pradam wrote:
>
> Hi Gophers,
>
> As for Newbie to Go.I am excited to learn a *web framework* but I 
> don't know where to start please help me out by suggesting a good framework 
> for beginners.
>
> 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.

[go-nuts] Ensuring resource cleanup when app is killed

[Tamás Gulácsi]

func main() {
  if err := Main(); err != nil {
log.Fatal(err)
  }
}

func Main() error {
  ctx, cancel := cintext.WithCanvel(context.Background())
  defer cancel()
  sigCh := make(chan signal.Signal, 1)
  go func() {
<-sigCh
cancel()
  }
  signal.Notify(sigCh, signal.Interrupt)

  ...

  return nil
}

-- 
You received this message because you are subscribed to the Google 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] Web Framework for Beginners

[Burak Serdar]

Revel is a good one.

https://revel.github.io/

On Wed, Jan 24, 2018 at 6:49 AM, pradam  wrote:
> Hi Gophers,
>
> As for Newbie to Go.I am excited to learn a web framework but I don't know
> where to start please help me out by suggesting a good framework for
> beginners.
>
> 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.

[go-nuts] Web Framework for Beginners

[pradam]

Hi Gophers,

As for Newbie to Go.I am excited to learn a *web framework* but I
don't know where to start please help me out by suggesting a good framework
for beginners.

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.

[go-nuts] Re: "type MyByte byte", then how to convert []MyByte to []byte so that I can use bytes.Xyz functions for []MyByte?

[Volker Dobler]

See https://golang.org/doc/faq#convert_slice_with_same_underlying_type

On Wednesday, 24 January 2018 13:57:59 UTC+1, di...@veryhaha.com wrote:
>
> except unsafe ways.
>

Yes: explicit loop.

Why did you do type MyByte byte in the first place?
Extra methods on your byte?

V. 

-- 
You received this message because you are subscribed to the Google 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] "type MyByte byte", then how to convert []MyByte to []byte so that I can use bytes.Xyz functions for []MyByte?

[Ian Davis]

A loop is the usual way.


On Wed, 24 Jan 2018, at 12:57 PM, d...@veryhaha.com wrote:
> except unsafe ways.
> 


> --
>  You received this message because you are subscribed to the Google
>  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] Ensuring resource cleanup when app is killed

[Sundar Nadathur]

My golang application creates UNIX sockets in specific paths: 
/mypath/name1.sock, /mypath/name2.sock etc. It then launches a go routine 
that listens to one or more of those sockets. I need to ensure that they 
get cleaned up (removed) at the end. I tried the obvious thing -- use defer 
in main() -- and eschewed the use of os.Exit() and log.Fatal(), since they 
don't ensure that defer statements are called.

However, signals like ^C also apparently cause forced termination and don't 
run the defer statements. So, I have experimented with a signal handler 
registered from main(). However, it seems that the ^C is going to the go 
routine that is actually listening on the socket: I don't see the signal 
handler running.

What is a good way to ensure that the resources are always cleaned up even 
in the presence of go routines and signals?

I have looked at related posts like 

 these .

-- 
You received this message because you are subscribed to the Google 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] "type MyByte byte", then how to convert []MyByte to []byte so that I can use bytes.Xyz functions for []MyByte?

[digg]

except unsafe ways.

-- 
You received this message because you are subscribed to the Google 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: Email sent via command line is not delivered in Golang

[Ain]

Cross-posted to 
SO: 
https://stackoverflow.com/questions/48421688/email-sent-via-command-line-is-not-delivered-in-golang


ain


kolmapäev, 24. jaanuar 2018 13:49.05 UTC+2 kirjutas Amandeep Kaur:
>
>
>
>
> I am sending emails in one of my projects through command line. The 
> project back end is written in Golang. I am using following code to send 
> emails:
>
 

-- 
You received this message because you are subscribed to the Google 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] Email sent via command line is not delivered in Golang

[Amandeep Kaur]

I am sending emails in one of my projects through command line. The project 
back end is written in Golang. I am using following code to send emails:



package utils


import(
"bytes"
"html/template"
"os/exec"
"fmt"
)

type EmailRequest struct{
EmailTo  string
EmailSubject string
EmailBodystring
}

func (request *EmailRequest) EmailSend(notificationTemplateData 
interface{}) (bool, error) {
subject, errParse := ParseTemplate(request.EmailSubject, 
notificationTemplateData)
body, errParse:= ParseTemplate(request.EmailBody, 
notificationTemplateData)
if errParse != nil{
return false, errParse
}
err := ExecuteMailCommand("mail -s \"$(echo \" "+subject+" \nMIME-version: 
1.0;\nContent-Type: text/html;charset=\"UTF-8\";\n\")\"  "+request.EmailTo, 
body)
if err != nil {
return false, err
}

return true, nil
}


func ParseTemplate(templateHtml string, data interface{}) (string, error) {
var body string
t, err := template.New("test").Parse(templateHtml)
if err != nil {
return body, err
}
buf := new(bytes.Buffer)

if err = t.Execute(buf, data); err != nil {
return body, err
}
body = buf.String()
return body, nil
}

   func ExecuteMailCommand(command string, body string) error {
cmd := exec.Command("sh", "-c", command)
cmd.Stdin = bytes.NewBufferString(body)

stdout, err := cmd.CombinedOutput()
if err != nil {
fmt.Printf("%v\n", err)
return err
}

fmt.Printf("%s\n", stdout)
return nil
}


But while sending email through this code, strange thing is happening. 
Sometimes the email is delivered immediately. But sometimes it is not 
delivered even upto somehours. The server is running on AWS.

I am not getting the reason why it is behaving like this. Do I need to set 
some server mail configurations or there is some problem in the code ?/

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] Unused code warnings

[mrx]

On Tue, Jan 23, 2018 at 2:53 PM, Paul Jolly  wrote:

> Take a look at unused:
>
> https://github.com/dominikh/go-tools
>
> That will help you to eliminate unused code pre compile time.
>

Thanks a lot, that will help for sure!

// Patrik

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