Re: [go-nuts] nil map assignment panics. can we do better?

[abuchanan via golang-nuts]

Ah, thanks Ian, that's exactly the kind of requirement I was looking for.

(also, you said "without" but you probably meant "while")

Perhaps this is a job for "go vet". And/or, looks like staticcheck.io has a 
check I can try: https://staticcheck.io/docs/checks#SA5000





On Monday, September 23, 2019 at 9:45:37 PM UTC-7, Ian Lance Taylor wrote:
>
> On Mon, Sep 23, 2019 at 2:40 PM abuchanan via golang-nuts 
> > wrote: 
> > 
> > Is there anything written down on why assignment to a nil map causes a 
> panic? I'm curious if there were carefully considered tradeoffs while 
> making this decision. 
> > 
> > Assignment to nil maps has caused most of the unexpected panics I've 
> seen. Many times these happen in production and cause an incident. Every 
> time it happens I think, "we've got to do something about this." 
> > 
> > I'm not sure what the best solution is yet, but there must be something 
> better than the status quo. Would it be possible to have assignments 
> automatically initialize a nil map? 
>
> I agree that this is awkward.  But we've never been able to think of a 
> way to make an assignment to a nil map initialize the map without also 
> preserving the very useful property that the zero value of any Go type 
> can be represented by a sequence of zero bytes. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d9cc8fb3-7d73-48c0-8c60-9d9b1022054c%40googlegroups.com.

[go-nuts] Re: VsCode syntax highlighting for tmpl files

[Subramanian Sridharan]

Nunjucks seems to do the trick.

Nunjucks - Visual Studio Marketplace 


ext install extension nunjucks
>

When you save a file with some file extension, VSCode automatically prompts 
you to install a related VSCode extension.
That's how I came to know about this extension. 

On Monday, September 23, 2019 at 8:55:52 PM UTC+5:30, cinem...@gmail.com 
wrote:
>
> Is there way to highlight templates files (.tmpl) in VSCode? There is an 
> extension gotemplate-syntax 
>  
> but 
> seems it doesn't make the job.
>
>
> {{define "side"}}
> New Books
> There's nothing here
> {{end}}
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a4f50184-e5d9-454a-b576-39ffab9c8327%40googlegroups.com.

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

[Kurtis Rader]

On Mon, Sep 23, 2019 at 9:38 PM Dan Kortschak  wrote:

> Have you ever considered using Go as the configuration format for your
> project? Have you wondered whether you need a Turing complete
> configuration language?
>
> Of course not; here it is: https://github.com/kortschak/yaegiconf
>
> Appalled? OK.
>

That's cool from a "here is how this can this be implemented" standpoint.
But, yeah, Turing complete config file formats are a truly, exceedingly,
bad idea. If for no other reason than the obvious one: It makes it
impossible to implement a parser and evaluator for the format in a
different language. Which should always be possible for a config file
format.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8Qi8JFA4WSCU7TLuXmgjx-WcAzJcuDdV08XSwz%2Bicziw%40mail.gmail.com.

Re: [go-nuts] Unable to post on this subject

[Ian Lance Taylor]

On Mon, Sep 23, 2019 at 8:26 AM  wrote:
>
>
> Trying to post on the golang-nuts subject but I get:
>
>
>
> ‘An Error occurred while communicating with the server’ RELOAD
>
>
>
> I have tried different laptops with Windows and Linux OS.
>
>
>
> Don’t know if it’s me of the thread as there is no error details or reason.
>
>
>
> Any Ideas?


This may have been due to list moderation.  As it says at
https://groups.google.com/forum/?pli=1#!forum/golang-nuts: "Note: This
group is moderated. If you are a first-time poster it may take 24
hours for your post to appear in the group."

My life would be noticeably simpler if more people read that note.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX1WGzmPPyjL8F-r1mOR2X4W_k%2BaK%2BOeGQHN8Ld%3DqXZ7A%40mail.gmail.com.

Re: [go-nuts] nil map assignment panics. can we do better?

[Ian Lance Taylor]

On Mon, Sep 23, 2019 at 2:40 PM abuchanan via golang-nuts
 wrote:
>
> Is there anything written down on why assignment to a nil map causes a panic? 
> I'm curious if there were carefully considered tradeoffs while making this 
> decision.
>
> Assignment to nil maps has caused most of the unexpected panics I've seen. 
> Many times these happen in production and cause an incident. Every time it 
> happens I think, "we've got to do something about this."
>
> I'm not sure what the best solution is yet, but there must be something 
> better than the status quo. Would it be possible to have assignments 
> automatically initialize a nil map?

I agree that this is awkward.  But we've never been able to think of a
way to make an assignment to a nil map initialize the map without also
preserving the very useful property that the zero value of any Go type
can be represented by a sequence of zero bytes.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV2XgwS-C-FKvBfSNp3unYdEfk0K2OZZywCZUTAtU-%3D0w%40mail.gmail.com.

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

[Dan Kortschak]

Have you ever considered using Go as the configuration format for your
project? Have you wondered whether you need a Turing complete
configuration language?

Of course not; here it is: https://github.com/kortschak/yaegiconf

Appalled? OK.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/62b6d16137dd38976c7ad3e1133d70f2e592db14.camel%40kortschak.io.

Re: [go-nuts] HTTP:ListenAndServe questions

[joe mcguckin]

Thanks!

That clears up a couple of nagging questions I had.

Joe

On Monday, September 23, 2019 at 7:45:16 PM UTC-7, Ben Burwell wrote:
>
> On Mon Sep 23, 2019 at 5:50 PM joe mcguckin wrote: 
> > In ListenAndServe, I see that it calls (*Server).Serve(ln), then 'go 
> c.serve(ctx)' 
> > I can't find a function named 'serve'. Where is this? 
>
> On line 1760 of the same file, server.go. 
>
> > Does HTTP manage a pool of coroutines or does it create one for every 
> > incoming HTTP request. 
>
> A new goroutine is created to handle each connection from the listener. 
>
> > It's clear where the first request gets handled 
> > but where do subsequent requests get handled? 
>
> Subsequent requests get handled in the same manner. Note that `go 
> c.serve(ctx)` is in a loop which blocks waiting for a new connection 
> (with `l.Accept()`). Once the goroutine has been dispatched to handle 
> the request, the main goroutine returns to waiting for the next request. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f839acf3-c388-480e-b3a0-35da08424037%40googlegroups.com.

Re: [go-nuts] HTTP:ListenAndServe questions

[Ben Burwell]

On Mon Sep 23, 2019 at 5:50 PM joe mcguckin wrote:
> In ListenAndServe, I see that it calls (*Server).Serve(ln), then 'go 
> c.serve(ctx)' 
> I can't find a function named 'serve'. Where is this?

On line 1760 of the same file, server.go.

> Does HTTP manage a pool of coroutines or does it create one for every 
> incoming HTTP request.

A new goroutine is created to handle each connection from the listener.

> It's clear where the first request gets handled
> but where do subsequent requests get handled?

Subsequent requests get handled in the same manner. Note that `go
c.serve(ctx)` is in a loop which blocks waiting for a new connection
(with `l.Accept()`). Once the goroutine has been dispatched to handle
the request, the main goroutine returns to waiting for the next request.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/BX7VZ4GS19W8.39TY5199T9JP%40jupiter.local.

Re: [go-nuts] package_test can't find local package

[Dan Kortschak]

Resolved.

Module name must be fully qualified.

On Tue, 2019-09-24 at 11:19 +0930, Dan Kortschak wrote:
> I'm putting together a tiny package at the moment that has not yet
> been
> push to a git remote. When I try to run tests I get the following
> failure:
> 
> $ GOPROXY=off go test
> # yaegiconf
> package yaegiconf_test
>   imports github.com/kortschak/yaegiconf: cannot find module
> providing package github.com/kortschak/yaegiconf
> FAIL  yaegiconf [setup failed]
> 
> (It's noisier with the proxy on).
> 
> There is a go.mod file in the directory that both the package code
> and
> the test code reside in. Is the go tool trying to go to the (non-
> existent) repo because it's "package_test" importing "package"? How
> do
> you work around this; it doesn't seem like a replace is going to work
> here. Surely this should just work.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/86dcb0f4d85dc35e28241802cf7f43d51b82aa43.camel%40kortschak.io.

[go-nuts] package_test can't find local package

[Dan Kortschak]

I'm putting together a tiny package at the moment that has not yet been
push to a git remote. When I try to run tests I get the following
failure:

$ GOPROXY=off go test
# yaegiconf
package yaegiconf_test
imports github.com/kortschak/yaegiconf: cannot find module
providing package github.com/kortschak/yaegiconf
FAILyaegiconf [setup failed]

(It's noisier with the proxy on).

There is a go.mod file in the directory that both the package code and
the test code reside in. Is the go tool trying to go to the (non-
existent) repo because it's "package_test" importing "package"? How do
you work around this; it doesn't seem like a replace is going to work
here. Surely this should just work.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c07ca20d2d7d70b8ad7d0a38af09148f07cb7cbc.camel%40kortschak.io.

[go-nuts] HTTP:ListenAndServe questions

[joe mcguckin]

In ListenAndServe, I see that it calls (*Server).Serve(ln), then 'go 
c.serve(ctx)' 
I can't find a function named 'serve'. Where is this?

Does HTTP manage a pool of coroutines or does it create one for every 
incoming HTTP request. It's clear where the first request gets handled
but where do subsequent requests get handled?

Thanks,

Joe

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c975193a-7b69-4ba2-ad99-3499cf01d726%40googlegroups.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

['Keith Randall' via golang-nuts]

In the runtime we use structs like these, but with unsafe.Pointer data 
fields (runtime.stringStruct and runtime.slice). They are much safer to use 
than reflect's types with uintptr Data fields. Unfortunately we can't 
change reflect's types because of the Go 1 compatibility guarantee.

You can do the same thing the runtime does. Something like this would work, 
and hopefully catch any future changes which would break the implementation:

type stringHeader struct {
data unsafe.Pointer
len  int
}
type sliceHeader struct {
data unsafe.Pointer
len  int
cap  int
}

func init() {
// Check to make sure string header is what reflect thinks it is.
// They should be the same except for the type of the Data field.
if unsafe.Sizeof(stringHeader{}) != unsafe.Sizeof(reflect.StringHeader{}) {
panic("string layout has changed")
}
x := stringHeader{}
y := reflect.StringHeader{}
x.data = unsafe.Pointer(y.Data)
y.Data = uintptr(x.data)
x.len = y.Len

// same for slice
}



On Monday, September 23, 2019 at 9:38:27 AM UTC-7, Robert Engels wrote:
>
> As someone that has worked with a lot of similar libraries in the HFT 
> space - things like UnsafeString or FastString in Java I would caution 
> against doing this in Go - especially as proposed here. Taking an immutable 
> object like string and making it mutable by accident is a recipe for 
> disaster. You are almost always better mapping a struct with accessors and 
> letting Go escape analysis perform the work on the stack and keep the 
> safety. 
>
>
>
> On Sep 23, 2019, at 10:09 AM, Francis > 
> wrote:
>
> So I think the current state of unsafe conversions of string <-> []byte is 
> roughly
>
> 1. Use the reflect Slice/StringHeader struct. These structs give you clear 
> fields to set and read from. If the runtime representation of a string or 
> []byte ever changes then these structs should change to reflect this (they 
> have a non-backwards compatibility carve out in the comments). But this 
> also means that you run into all these exotic problems because these two 
> structs have a `uintpr` an `unsafe.Pointer` so for a short time the GC 
> won't realise you are reading/writing a pointer. This makes correct use of 
> these structs very difficult.
> 2. You can just cast between these two types going through 
> `unsafe.Pointer` on the way. This works, because these two types have 
> almost identical layouts. We don't use any uintptr at all and so the GC 
> probably won't get confused. But, if the representations of string or 
> []byte ever change then you code breaks silently, and could have very 
> weird/hard to track down problems.
>
> So I don't think `neither is safer than the other` is quite the right 
> description in this context. They both have problems, so they are both 
> not-perfect. But their problems are quite distinct. At the least if we 
> choose one over the other we can describe clearly which set of problems we 
> want to have.
>
> My hope was that someone had thought through these problems and could 
> indicate the right way to do it.
>
> On a related note. I was trying to track down where the Slice/StringHeader 
> was first introduced. It was a long time ago 
>
>  (10 years ago) 29e6eb21ec  (HEAD)
>
> make a description of the slice header public
>
> R=rsc
> DELTA=18  (3 added, 0 deleted, 15 changed)
> OCL=31086
> CL=31094
>
> Although I couldn't open that CL in gerrit (I assume user-error). From 
> reading the commit I think the intention was for these header structs to be 
> used for this or similar things. But the data was represented as a uintptr 
> and a comment explicitly states that these structs are of no use without 
> `unsafe.Pointer`. I have seen roughly three other CL which try to change 
> the data field to `unsafe.Pointer` but are rejected because they change the 
> reflect packages API.
>
> There is also this issue
>
> https://github.com/golang/go/issues/19367
>
> Which proposes that Slice/StringHeader be moved/duplicated in unsafe and 
> use `unsafe.Pointer`. As far as I can tell once we have this then all the 
> subtle problems disappear and lovingly crafted examples like
>
> https://github.com/m3db/m3x/blob/master/unsafe/string.go#L62
>
> just become the right way to do it.
>
> Until then maybe we should just rely on the structural similarities 
> between the two types and cast between them. This seems especially 
> appealing as Jan pointed out above that at least one of the hypothetical 
> problems isn't hypothetical at all.
>
>
> On Monday, 23 September 2019 12:43:34 UTC+2, kortschak wrote:
>>
>> Any particular reason for that? Neither is safer than the other and 
>> it's not clear to me that you can actually achieve the goal of having a 
>> compile-time check for the correctness of this type of conversion. 
>>
>> On Mon, 2019-09-23 at 02:36 -0700, fra...@adeven.com wrote: 
>> > But this relies on a string's representation being the same as, but a 
>> > bit smaller thabn, a []byte. I would prefer to use 
>> > the 

Re: [go-nuts] Need a Modules for Dummy's Guide. Please help

[Marcin Romaszewicz]

I've beat my head into the module wall a bit as well, and while I don't
understand some of the design decisions, I've done my best to answer your
questions inline.

On Mon, Sep 23, 2019 at 1:42 PM Stuart Davies  wrote:

> Hi.
>
>
>
> I have been using GO for about a year and I love the language and ideas
> behind the language.
>
>
>
> I am also a Java developer for many years, I switched from Delphi to Java
> 1, the new and exciting language from Sun (a bit like GO is now from
> Google).
>
>
>
> In Java we have Maven and Gradle (sorry Ant) to make dependency hell more
> manageable so I understand the need for modules in Go. I have just
> installed GO 1.13 and thought I would convert an existing 'pet' project to
> use modules. It did NOT go well!
>
>
>
> What I need is a dummies guide to GO module so I can build good, reliable,
> standards compliant GO applications.
>
>
>
> It needs to explain the new terminology in the context of a module, For
> example 'vendor'. Not just a one liner, I NEED to understand!
>
>
>
> I know how to use Google but the quality of the articles I have read on
> this subject is minimal and just brushes the surface.
>
>
>- If I have a reasonably large and complex (pet) project with
>local packages in it. I like to split my project in to small units with
>'namespaces' to keep it manageable. These are NOT reusable components until
>I decide they qualify and publish on Github. Why MUST I import them as if
>they are from github and then 'replace' them, and if I don’t 'MUST' then
>you have failed to explain this feature to me!
>
>
Go now has two distinct ways of finding dependencies. Module mode (export
GO111MODULE=on) and the non-module mode (export GO111MODULE=off). Each mode
resolves dependencies differently.

In Module mode, all imports are assumed to be paths to git version control
systems, such as github, and that's how they're always interpreted, that
was a design choice. If you have a local directory with source code that's
not on a git server with a matching name, that's when you use the 'replace'
directive to point it at the local directory, otherwise, Go will try to
contact that server.

Github doesn't have to be in the name, for example, you could make a
/tmp/stuart/mymodule "namespace", import it as "fake.host/stuart/mymodule",
and you'd have to specify a "replace fake.host/stuart/mymodule =>
/tmp/stuart/mymodule" directive.

With modules turned off, things make a little bit more sense. Imports are
just strings, so "import foo/bar/baz" would try to import
$GOPATH/src/foo/bar/baz, and AFAIK, there aren't any restrictions on naming
these things.


>
>- My local packages are part of my application. They are, I agree
>still 'dependencies' but they are not 'DEPENDENCIES' that I need (or even
>want) to import from a repository. They are part of my project.
>
>
The easiest way to deal with this is to refactor your dependencies to be
subdirectories within your main project/module. If they're subdirectories,
and share one global go.mod file, you're not dependent on github or
anything, and this module can have any name. If you ever intend to publish
it for public consumption, though, you'd need to give it a github name.


>
>- What if I do not want to host my project on a GIT repo (Shock
>horror!).
>
>
Use non-module mode, where it's up to you to manage the contents of
$GOPATH/src, or put everything in the same module, since the name doesn't
matter when you're operating within a module's directory tree.


>
>- Why do all imports start with github.com. Is that a requirement,
>what is the rational for this.
>
>
They must start with a hostname resolvable to a git server, that's all. For
example, gopkg.in shows up a lot as well. I have my own internal gerrit
server, and I use that hostname. This behavior is documented here:
https://golang.org/cmd/go/#hdr-Remote_import_paths

It appears that several version control systems are special cased.


>
>- How does a 'import' resolve its 'reference'.
>
>
In module mode, it contacts the server at your import path, with a query
saying that it's Go asking the question, and it expects a code location
back as an answer, it's documented here in that link above. If you "import
foo.com/bar", Go issues the query "https://foo.com/bar?go-get=1;, and
expects some VCS meta-info back as a response. That tells Go that we're
talking to Git or Mercurial or whatever, as well as the actual path to the
repository.

>
>- Should I add the go.mod and go.sum files to my repository or
>should the developer who cloned my project have to do a go mod init
>(bummer!).
>
> Can someone please explain, properly!
>

Your go.mod and go.sum should go into your repository. Together, they
unambiguously specify _your_ set of dependencies. It's up to you to manage
them in a way which makes your library function properly, and when others
clone it, they can be assured that they're getting the 

[go-nuts] Re: go 1.13 won't compile

[Robert Solomon]

If I understand you,  you want me to not use ~/go/sec?  That confuses me.  Am I 
getting expected behavior? 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f63f63cb-1d45-4971-a245-55a62273d3f2%40googlegroups.com.

[go-nuts] Re: Unable to post on this subject

[Stuart Davies]

It's ok now. Got my post done. Thanks.



On Monday, 23 September 2019 16:26:15 UTC+1, stuart...@bt.com wrote:
>
> Hi
>
>  
>
> Trying to post on the golang-nuts subject but I get:
>
>  
>
> ‘An Error occurred while communicating with the server’ RELOAD
>
>  
>
> I have tried different laptops with Windows and Linux OS.
>
>  
>
> Don’t know if it’s me of the thread as there is no error details or reason.
>
>  
>
> Any Ideas?
>
>  
>
> Regards
>
>  
>
> Stuart Davies (BT Technology) Senior Software Engineer.
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c587ec5a-6c59-42d9-a921-377b7750d7e2%40googlegroups.com.

[go-nuts] nil map assignment panics. can we do better?

[abuchanan via golang-nuts]

Is there anything written down on why assignment to a nil map causes a 
panic? I'm curious if there were carefully considered tradeoffs while 
making this decision.

Assignment to nil maps has caused most of the unexpected panics I've seen. 
Many times these happen in production and cause an incident. Every time it 
happens I think, "we've got to do something about this."

I'm not sure what the best solution is yet, but there must be something 
better than the status quo. Would it be possible to have assignments 
automatically initialize a nil map?

Thanks,
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/94f7ab01-f2c3-4fe6-8503-a831ffb46615%40googlegroups.com.

[go-nuts] Re: Unable to post on this subject

[cinematown]

well, google is awesome but is not perfect  :)

On Monday, September 23, 2019 at 6:26:15 PM UTC+3, stuart...@bt.com wrote:
>
> Hi
>
>  
>
> Trying to post on the golang-nuts subject but I get:
>
>  
>
> ‘An Error occurred while communicating with the server’ RELOAD
>
>  
>
> I have tried different laptops with Windows and Linux OS.
>
>  
>
> Don’t know if it’s me of the thread as there is no error details or reason.
>
>  
>
> Any Ideas?
>
>  
>
> Regards
>
>  
>
> Stuart Davies (BT Technology) Senior Software Engineer.
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c396592f-87a5-409a-a2c3-099a87dc5982%40googlegroups.com.

[go-nuts] Need a Modules for Dummy's Guide. Please help

[Stuart Davies]

Hi.

 

I have been using GO for about a year and I love the language and ideas 
behind the language.

 

I am also a Java developer for many years, I switched from Delphi to Java 
1, the new and exciting language from Sun (a bit like GO is now from 
Google).

 

In Java we have Maven and Gradle (sorry Ant) to make dependency hell more 
manageable so I understand the need for modules in Go. I have just 
installed GO 1.13 and thought I would convert an existing 'pet' project to 
use modules. It did NOT go well!

 

What I need is a dummies guide to GO module so I can build good, reliable, 
standards compliant GO applications.

 

It needs to explain the new terminology in the context of a module, For 
example 'vendor'. Not just a one liner, I NEED to understand!

 

I know how to use Google but the quality of the articles I have read on 
this subject is minimal and just brushes the surface.


   - If I have a reasonably large and complex (pet) project with local 
   packages in it. I like to split my project in to small units with 
   'namespaces' to keep it manageable. These are NOT reusable components until 
   I decide they qualify and publish on Github. Why MUST I import them as if 
   they are from github and then 'replace' them, and if I don’t 'MUST' then 
   you have failed to explain this feature to me!
   - My local packages are part of my application. They are, I agree 
   still 'dependencies' but they are not 'DEPENDENCIES' that I need (or even 
   want) to import from a repository. They are part of my project.
   - What if I do not want to host my project on a GIT repo (Shock 
   horror!).
   - Why do all imports start with github.com. Is that a requirement, 
   what is the rational for this.
   - How does a 'import' resolve its 'reference'.
   - Should I add the go.mod and go.sum files to my repository or 
   should the developer who cloned my project have to do a go mod init 
   (bummer!).

Can someone please explain, properly!

 

We must have Modules and Repositories (like Maven Central) for the 
'Enterprise' to manage dependencies but what about 'keep it simple' for the 
rest of us (and for that matter more mature enterprise developers like 
myself).

 

Please help me get this understood. This is the sort of thing that can 
raise a language above the rest and I would really like that to happen. Go 
is brilliant…

 

Regards

 

Stuart

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b79c351d-5657-4ee7-bfd9-c3294d8bbf95%40googlegroups.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[Robert Engels]

As someone that has worked with a lot of similar libraries in the HFT space - 
things like UnsafeString or FastString in Java I would caution against doing 
this in Go - especially as proposed here. Taking an immutable object like 
string and making it mutable by accident is a recipe for disaster. You are 
almost always better mapping a struct with accessors and letting Go escape 
analysis perform the work on the stack and keep the safety. 



> On Sep 23, 2019, at 10:09 AM, Francis  wrote:
> 
> So I think the current state of unsafe conversions of string <-> []byte is 
> roughly
> 
> 1. Use the reflect Slice/StringHeader struct. These structs give you clear 
> fields to set and read from. If the runtime representation of a string or 
> []byte ever changes then these structs should change to reflect this (they 
> have a non-backwards compatibility carve out in the comments). But this also 
> means that you run into all these exotic problems because these two structs 
> have a `uintpr` an `unsafe.Pointer` so for a short time the GC won't realise 
> you are reading/writing a pointer. This makes correct use of these structs 
> very difficult.
> 2. You can just cast between these two types going through `unsafe.Pointer` 
> on the way. This works, because these two types have almost identical 
> layouts. We don't use any uintptr at all and so the GC probably won't get 
> confused. But, if the representations of string or []byte ever change then 
> you code breaks silently, and could have very weird/hard to track down 
> problems.
> 
> So I don't think `neither is safer than the other` is quite the right 
> description in this context. They both have problems, so they are both 
> not-perfect. But their problems are quite distinct. At the least if we choose 
> one over the other we can describe clearly which set of problems we want to 
> have.
> 
> My hope was that someone had thought through these problems and could 
> indicate the right way to do it.
> 
> On a related note. I was trying to track down where the Slice/StringHeader 
> was first introduced. It was a long time ago 
> 
>  (10 years ago) 29e6eb21ec  (HEAD)
> 
> make a description of the slice header public
> 
> R=rsc
> DELTA=18  (3 added, 0 deleted, 15 changed)
> OCL=31086
> CL=31094
> 
> Although I couldn't open that CL in gerrit (I assume user-error). From 
> reading the commit I think the intention was for these header structs to be 
> used for this or similar things. But the data was represented as a uintptr 
> and a comment explicitly states that these structs are of no use without 
> `unsafe.Pointer`. I have seen roughly three other CL which try to change the 
> data field to `unsafe.Pointer` but are rejected because they change the 
> reflect packages API.
> 
> There is also this issue
> 
> https://github.com/golang/go/issues/19367
> 
> Which proposes that Slice/StringHeader be moved/duplicated in unsafe and use 
> `unsafe.Pointer`. As far as I can tell once we have this then all the subtle 
> problems disappear and lovingly crafted examples like
> 
> https://github.com/m3db/m3x/blob/master/unsafe/string.go#L62
> 
> just become the right way to do it.
> 
> Until then maybe we should just rely on the structural similarities between 
> the two types and cast between them. This seems especially appealing as Jan 
> pointed out above that at least one of the hypothetical problems isn't 
> hypothetical at all.
> 
> 
>> On Monday, 23 September 2019 12:43:34 UTC+2, kortschak wrote:
>> Any particular reason for that? Neither is safer than the other and 
>> it's not clear to me that you can actually achieve the goal of having a 
>> compile-time check for the correctness of this type of conversion. 
>> 
>> On Mon, 2019-09-23 at 02:36 -0700, fra...@adeven.com wrote: 
>> > But this relies on a string's representation being the same as, but a 
>> > bit smaller thabn, a []byte. I would prefer to use 
>> > the Slice/StringHeader. 
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/422ca2bd-d6c8-4ebe-9578-8dd3cd8317e9%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/18E58C67-6A81-4EBB-B61B-02129BD412E7%40ix.netcom.com.

Re: [go-nuts] Dependency injection in gorillamux handlers

['Abhinav Gupta' via golang-nuts]

You can place the dependencies into a struct and use a bound method on that
as your handler. So you build a struct that will hold application-scoped
objects like Redis client, content.Updater, etc.

package contact

type Handler struct {
Redis   *redis.Client
Updater *content.Updater
Mapper  *mapping.Updater
}

func (h *Handler) Endpoint1(w http.ResponseWriter, r *http.Request) {
// ...
}

Then build the Handler when you’re setting up the router (presumably in
main() or nearby) and register it against the router as usual.

handler := contact.Handler{
Redis:   config.GetRedisDb(),
Updater: contents.GetUpdater(),
Mapper:  mapping.GetUpdater(),
}

myRouter.Handle("/endpoint1/",
http.HandlerFunc(h.Endpoint1)).Methods("POST", "OPTIONS")
// or
myRouter.HandleFunc("/endpoint1/", h.Endpoint1).Methods("POST", "OPTIONS")



On Mon, Sep 23, 2019 at 2:37 AM Nathanael Curin 
wrote:

> I'm avoiding context.WithValue since I feel the objects I'm dealing with
> are too "powerful" (i.e. not simple Values). For a read, a 2016 article on
> this : https://peter.bourgon.org/blog/2016/07/11/context.html
>
> 
> I remember reading through another article saying the usage of WithValue
> is kind of risky when time goes on, since it's just a magical interface{}
> store. Performance-wise I'm not sure though.
>
> Though, you're right, that'd be another way to do it. Waiting for people
> to chime in with their ideas too (hopefully!) :)
>
>
> Le lundi 23 septembre 2019 11:20:52 UTC+2, Andrew Pillar a écrit :
>>
>> Why don't you use context.WithValue(r.Context(), , ) for
>> passing
>> the injected values you want to your HTTP handlers. Then defer the logic
>> for
>> retrieving whatever you want for that handler to a middleware function.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c23761e8-1287-4758-8303-b39db8cf22f0%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGeKYdXhUsfE0_ETFTCKKU1kJyY2zqfWJ8HeikaiYoC8%2B05u2Q%40mail.gmail.com.

Re: [go-nuts] GO Mod (modules) for dummies. Please help.

[Ian Davis]

Hi,

On Mon, 23 Sep 2019, at 11:04 AM, sdd.dav...@gmail.com wrote:
> 
> If I have a reasonably large and complex (pet) project with local packages in 
> it. I like to split my project in to small units with 'namespaces' to keep it 
> manageable. These are NOT reusable components until I decide they qualify and 
> publish on Github.

>  * Why MUST I import them as if they are from github and then 'replace' them, 
> and if I don’t 'MUST' then you have failed to explain this feature to me!

Can you provide an example of what you are doing or a link to the documentation 
that is telling you to do this?

Every module in Go has a name and when you have modules in different locations, 
even just peer directories on your local machine, you need to write the mapping 
in go.mod between the name of the module and its location. For example, I have 
a non-public library that is used by another module on my machine. I have this 
in my go.mod to link the two together without needing to publish the library: 
replace ian.local/tools => ../tools


>  * My local packages are part of my application. They are, I agree still 
> 'dependencies' but they are not 'DEPENDENCIES' that I need (or even want) to 
> import from a repository. They are part of my project.

That's fine. Packages that are in subdirectories are usually simply part of the 
parent module. However you still need to name them so you can import them in 
your code. The pattern is that each package name is appended to the module name 
like a path, so in my example above a subpackage of tools would be referred to 
as ian.local/tools/subpackage


>  * What if I do not want to host my project on a GIT repo (Shock horror!).
The go tool also supports Bazaar, Fossil, Mercurial and Subversion. See 
https://golang.org/cmd/go/#hdr-Remote_import_paths



>  * Why do all imports start with github.com. Is that a requirement, what is 
> the rational for this.

It is not a requirement. You are simply seeing the consequences of 90% of 
packages being hosted there. You may also commonly see packages hosted at 
golang.org, gopkg.in, bitbucket.org and many others. There are no restrictions 
and you can host on your own domain. 


>  * How does a 'import' resolve its 'reference'.

The go tool uses go.mod to find out how to resolve a package name. Usually it 
simply maps directly to a remote repository (in which case go.mod will also 
contain some version information) but it could also map to another compatible 
package or to a location on your local machine.


>  * Should I add the go.mod and go.sum files to my repository or should the 
> developer who cloned my project have to do a go mod init (bummer!).
> 

You should do it. Give your module a name so people know what to use when 
importing it. As far as I know the only restriction is that the name must have 
a dot in it. By convention people name their modules with the repository name 
but that is not required. If you don't plan to share your code then you can 
make up a name like I did above: example.local works for instance.


> *Can someone please explain, properly!*

I feel your pain! Modules are conceptually simple (a collection of related 
packages) but the interactions with code repositories, tools, build systems and 
user expectations are phenomenally complicated. The documentation is 
comprehensive and extensive but still misses some important "getting started" 
information. If you have specific requirements or problems with it then raising 
an issue for the Go team to track would be useful.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/66c4b89f-d0bd-43d7-b46f-77c9be680092%40www.fastmail.com.

[go-nuts] Unable to post on this subject

[stuart.d.davies]

Hi

Trying to post on the golang-nuts subject but I get:

'An Error occurred while communicating with the server' RELOAD

I have tried different laptops with Windows and Linux OS.

Don't know if it's me of the thread as there is no error details or reason.

Any Ideas?

Regards

Stuart Davies (BT Technology) Senior Software Engineer.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a7bd15d345d747c08fd859cc4736b586%40tpw09926dag18g.domain1.systemhost.net.

[go-nuts] VsCode syntax highlighting for tmpl files

[cinematown]

Is there way to highlight templates files (.tmpl) in VSCode? There is an 
extension gotemplate-syntax 
 but 
seems it doesn't make the job.


{{define "side"}}
New Books
There's nothing here
{{end}}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5987dbe0-b2e8-4ac2-ac6d-e3725501f504%40googlegroups.com.

[go-nuts] GO Mod (modules) for dummies. Please help.

[sdd . davies]

 

Hi. 


I have been using GO for about a year and I love the language and ideas 
behind the language. I am also a Java developer for many years, I switched 
from Delphi to Java 1, the new and exciting language from Sun (a bit like 
GO is now from Google).

 

In Java we have Maven and Gradle (sorry Ant) to make dependency hell more 
manageable so I understand the need for modules in Go. I have just 
installed GO 1.13 and thought I would convert an existing 'pet' project to 
use modules. It did NOT go well!

 

What I need is a dummies guide to the GO module so I can build good, 
reliable, standards compliant GO applications.

 

I needs to explain the new terminology in the context of a module, like 
'vendor'.  Not just a one liner, I NEED to understand! 

 

I know how to use Google but the quality of the articles I have read on 
this subject is minimal and just brushes the surface.

 

If I have a reasonably large and complex (pet) project with local packages 
in it. I like to split my project in to small units with 'namespaces' to 
keep it manageable. These are NOT reusable components until I decide they 
qualify and publish on Github.

   - Why MUST I import them as if they are from github and then 'replace' 
   them, and if I don’t 'MUST' then you have failed to explain this feature to 
   me!
   - My local packages are part of my application. They are, I agree still 
   'dependencies' but they are not 'DEPENDENCIES' that I need (or even want) 
   to import from a repository. They are part of my project.
   - What if I do not want to host my project on a GIT repo (Shock 
   horror!). 
   - Why do all imports start with github.com. Is that a requirement, what 
   is the rational for this. 
   - How does a 'import' resolve its 'reference'. 
   - Should I add the go.mod and go.sum files to my repository or should 
   the developer who cloned my project have to do a go mod init (bummer!).
   
*Can someone please explain, properly!* 

We must have Modules and Repositories (like Maven Central) for the 
'Enterprise' to manage dependencies but what about 'keep it simple' for the 
rest of us (and for that matter more mature enterprise developers like 
myself).

 

Please help me get this understood. This is the sort of thing that can 
raise a language above the rest and I would really like that to happen. Go 
is brilliant…

 

Regards

 

Stuart

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/80c7f7dd-d30b-4796-8198-d083b29f58f8%40googlegroups.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[Francis]

So I think the current state of unsafe conversions of string <-> []byte is 
roughly

1. Use the reflect Slice/StringHeader struct. These structs give you clear 
fields to set and read from. If the runtime representation of a string or 
[]byte ever changes then these structs should change to reflect this (they 
have a non-backwards compatibility carve out in the comments). But this 
also means that you run into all these exotic problems because these two 
structs have a `uintpr` an `unsafe.Pointer` so for a short time the GC 
won't realise you are reading/writing a pointer. This makes correct use of 
these structs very difficult.
2. You can just cast between these two types going through `unsafe.Pointer` 
on the way. This works, because these two types have almost identical 
layouts. We don't use any uintptr at all and so the GC probably won't get 
confused. But, if the representations of string or []byte ever change then 
you code breaks silently, and could have very weird/hard to track down 
problems.

So I don't think `neither is safer than the other` is quite the right 
description in this context. They both have problems, so they are both 
not-perfect. But their problems are quite distinct. At the least if we 
choose one over the other we can describe clearly which set of problems we 
want to have.

My hope was that someone had thought through these problems and could 
indicate the right way to do it.

On a related note. I was trying to track down where the Slice/StringHeader 
was first introduced. It was a long time ago 

 (10 years ago) 29e6eb21ec  (HEAD)

make a description of the slice header public

R=rsc
DELTA=18  (3 added, 0 deleted, 15 changed)
OCL=31086
CL=31094

Although I couldn't open that CL in gerrit (I assume user-error). From 
reading the commit I think the intention was for these header structs to be 
used for this or similar things. But the data was represented as a uintptr 
and a comment explicitly states that these structs are of no use without 
`unsafe.Pointer`. I have seen roughly three other CL which try to change 
the data field to `unsafe.Pointer` but are rejected because they change the 
reflect packages API.

There is also this issue

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

Which proposes that Slice/StringHeader be moved/duplicated in unsafe and 
use `unsafe.Pointer`. As far as I can tell once we have this then all the 
subtle problems disappear and lovingly crafted examples like

https://github.com/m3db/m3x/blob/master/unsafe/string.go#L62

just become the right way to do it.

Until then maybe we should just rely on the structural similarities between 
the two types and cast between them. This seems especially appealing as Jan 
pointed out above that at least one of the hypothetical problems isn't 
hypothetical at all.


On Monday, 23 September 2019 12:43:34 UTC+2, kortschak wrote:
>
> Any particular reason for that? Neither is safer than the other and 
> it's not clear to me that you can actually achieve the goal of having a 
> compile-time check for the correctness of this type of conversion. 
>
> On Mon, 2019-09-23 at 02:36 -0700, fra...@adeven.com  wrote: 
> > But this relies on a string's representation being the same as, but a 
> > bit smaller thabn, a []byte. I would prefer to use 
> > the Slice/StringHeader. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/422ca2bd-d6c8-4ebe-9578-8dd3cd8317e9%40googlegroups.com.

[go-nuts] Any support for proxy certificates (RFC3820) ?

[Christophe Meessen]

Hello,
I need to write go code dealing with proxy certificates (RFC3820). 
They are sometimes referred to as Grid Security Infrastructure (GSI) 
certificates

I couldn’t find anything related in crypto or x/crypto. Any suggestion ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b513edb2-e49a-424e-a9b8-326295c5ce42%40googlegroups.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[Dan Kortschak]

Any particular reason for that? Neither is safer than the other and
it's not clear to me that you can actually achieve the goal of having a
compile-time check for the correctness of this type of conversion.

On Mon, 2019-09-23 at 02:36 -0700, fran...@adeven.com wrote:
> But this relies on a string's representation being the same as, but a
> bit smaller thabn, a []byte. I would prefer to use 
> the Slice/StringHeader.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cd1b5e5e5d6f8dd42c9f2f61196f122671017064.camel%40kortschak.io.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[francis]

That's super interesting. Thanks for the pointer Jan :bow:

On Monday, September 23, 2019 at 11:42:55 AM UTC+2, Jan Mercl wrote:
>
> On Mon, Sep 23, 2019 at 11:37 AM > wrote: 
>
> > ... and the problems with storing a uinptr in a variable are mostly 
> related to moving garbage collectors ... 
>
> Please note that even though, AFAIK, none of the Go compilers so far 
> uses a moving GC, it's not the only source of objects being moved 
> around. For a long time the gc Go compiler has moveable stacks and 
> things may reside in stack whenever the compiler decides it can and 
> wants to do it. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7a3e7abf-dffa-4f24-b940-51fa49cea8e7%40googlegroups.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[Jan Mercl]

On Mon, Sep 23, 2019 at 11:37 AM  wrote:

> ... and the problems with storing a uinptr in a variable are mostly related 
> to moving garbage collectors ...

Please note that even though, AFAIK, none of the Go compilers so far
uses a moving GC, it's not the only source of objects being moved
around. For a long time the gc Go compiler has moveable stacks and
things may reside in stack whenever the compiler decides it can and
wants to do it.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Wx-2yYwEL9pg2s9UX8Y7OMR0sfsFGd5R-Kje%2BmbhQ4sg%40mail.gmail.com.

Re: [go-nuts] Dependency injection in gorillamux handlers

[Nathanael Curin]

I'm avoiding context.WithValue since I feel the objects I'm dealing with 
are too "powerful" (i.e. not simple Values). For a read, a 2016 article on 
this : https://peter.bourgon.org/blog/2016/07/11/context.html
I remember reading through another article saying the usage of WithValue is 
kind of risky when time goes on, since it's just a magical interface{} 
store. Performance-wise I'm not sure though.

Though, you're right, that'd be another way to do it. Waiting for people to 
chime in with their ideas too (hopefully!) :)


Le lundi 23 septembre 2019 11:20:52 UTC+2, Andrew Pillar a écrit :
>
> Why don't you use context.WithValue(r.Context(), , ) for 
> passing 
> the injected values you want to your HTTP handlers. Then defer the logic 
> for 
> retrieving whatever you want for that handler to a middleware function. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c23761e8-1287-4758-8303-b39db8cf22f0%40googlegroups.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[francis]

That would work Kortschak.

But this relies on a string's representation being the same as, but a bit 
smaller thabn, a []byte. I would prefer to use the Slice/StringHeader.

It's worth noting that _most_ of the problems I described in my initial 
post are hypothetical at this stage. The issue with strings being garbage 
collected mid-conversion are (I think) certain not to happen in Go 1.12 and 
the problems with storing a uinptr in a variable are mostly related to 
moving garbage collectors (so long as the location your uintpr points to 
doesn't get garbage collected). But both of these facts have a reasonable 
likely hood of changing in the future.

The thing I would like the most is an pair of unsafe string <-> []byte 
conversion implementations which satisfy the rules of unsafe as they are 
written now which will _not_ compile if the representation of []byte/string 
changes in the future.

This was what I thought I would get using the reflect.Slice/StringHeader 
structs and some unsafe. It's surprising that this doesn't work in a 
straight-forward way.

On Saturday, September 21, 2019 at 8:11:08 AM UTC+2, kortschak wrote:
>
> func bytesToString(b []byte) string { 
> return *(*string)(unsafe.Pointer()) 
> } 
>
> https://play.golang.org/p/azJPbl946zj 
>
> On Fri, 2019-09-20 at 13:30 -0700, Francis wrote: 
> > Thanks Ian, that's a very interesting solution. 
> > 
> > Is there a solution for going in the other direction? Although I 
> > excluded 
> > it from the initial post, it was only to reduce the size of the 
> > discussion. 
> > I would also like to implement 
> > 
> > func BytesToString(b []byte) string { 
> > 
> > I don't clearly see how to avoid using the StringHeader in this case. 
> > 
> > F 
> > 
> > On Wednesday, 18 September 2019 22:46:44 UTC+2, Ian Lance Taylor 
> > wrote: 
> > > 
> > > On Wed, Sep 18, 2019 at 2:42 AM Francis  > > > wrote: 
> > > > 
> > > > I am looking at the correct way to convert from a byte slice to a 
> > > > string 
> > > 
> > > and back with no allocations. All very unsafe. 
> > > > 
> > > > I think these two cases are fairly symmetrical. So to simplify 
> > > > the 
> > > 
> > > discussion below I will only talk about converting from a string to 
> > > []byte. 
> > > > 
> > > > func StringToBytes(s string) (b []byte) 
> > > 
> > > No reason to use SliceHeader, and avoiding SliceHeader avoids the 
> > > problems you discuss. 
> > > 
> > > func StringToBytes(s string) []byte { 
> > > const max = 0x7fff 
> > > if len(s) > max { 
> > > panic("string too long") 
> > > } 
> > > return 
> > > (*[max]byte)(unsafe.Pointer((*reflect.StringHeader)(unsafe.Pointer( 
> > > )).Data))[:len(s):len(s)] 
> > > 
> > > } 
> > > 
> > > Of course, as you say, you must not mutate the returned []byte. 
> > > 
> > > Ian 
> > > 
> > 
> > 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8bff6f8e-487a-4c69-a55e-513855d846da%40googlegroups.com.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

[francis]

That would work Kortschak.

But this relies on a string's representation being the same as, but a bit 
smaller thabn, a []byte. I would prefer to use the Slice/StringHeader.

It's worth noting that _most_ of the problems I described in my initial 
post are hypothetical at this stage. The issue with strings being garbage 
collected mid-conversion are (I think) certain not to happen in Go 1.12 and 
the problems with storing a uinptr in a variable are mostly related to 
moving garbage collectors (so long as the location your uintpr points to 
doesn't get garbage collected). But both of these facts have a reasonable 
likely hood of changing in the future.

The thing I would like the most is an pair of unsafe string <-> []byte 
conversion implementations which satisfy the rules of unsafe as they are 
written now which will _not_ compile if the representation of []byte/string 
changes in the future.

This was what I thought I would get using the reflect.Slice/StringHeader 
structs and some unsafe. It's surprising that this doesn't work in a 
straight-forward way.

On Saturday, September 21, 2019 at 8:11:08 AM UTC+2, kortschak wrote:
>
> func bytesToString(b []byte) string { 
> return *(*string)(unsafe.Pointer()) 
> } 
>
> https://play.golang.org/p/azJPbl946zj 
>
> On Fri, 2019-09-20 at 13:30 -0700, Francis wrote: 
> > Thanks Ian, that's a very interesting solution. 
> > 
> > Is there a solution for going in the other direction? Although I 
> > excluded 
> > it from the initial post, it was only to reduce the size of the 
> > discussion. 
> > I would also like to implement 
> > 
> > func BytesToString(b []byte) string { 
> > 
> > I don't clearly see how to avoid using the StringHeader in this case. 
> > 
> > F 
> > 
> > On Wednesday, 18 September 2019 22:46:44 UTC+2, Ian Lance Taylor 
> > wrote: 
> > > 
> > > On Wed, Sep 18, 2019 at 2:42 AM Francis  > > > wrote: 
> > > > 
> > > > I am looking at the correct way to convert from a byte slice to a 
> > > > string 
> > > 
> > > and back with no allocations. All very unsafe. 
> > > > 
> > > > I think these two cases are fairly symmetrical. So to simplify 
> > > > the 
> > > 
> > > discussion below I will only talk about converting from a string to 
> > > []byte. 
> > > > 
> > > > func StringToBytes(s string) (b []byte) 
> > > 
> > > No reason to use SliceHeader, and avoiding SliceHeader avoids the 
> > > problems you discuss. 
> > > 
> > > func StringToBytes(s string) []byte { 
> > > const max = 0x7fff 
> > > if len(s) > max { 
> > > panic("string too long") 
> > > } 
> > > return 
> > > (*[max]byte)(unsafe.Pointer((*reflect.StringHeader)(unsafe.Pointer( 
> > > )).Data))[:len(s):len(s)] 
> > > 
> > > } 
> > > 
> > > Of course, as you say, you must not mutate the returned []byte. 
> > > 
> > > Ian 
> > > 
> > 
> > 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/abb6b5e2-2e56-42c9-910c-ed00fa6259f5%40googlegroups.com.

Re: [go-nuts] Dependency injection in gorillamux handlers

[Andrew Pillar]

Why don't you use context.WithValue(r.Context(), , ) for passing
the injected values you want to your HTTP handlers. Then defer the logic for
retrieving whatever you want for that handler to a middleware function.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/732f914e-e99d-4473-bafa-cf624e65af6d%40www.fastmail.com.

[go-nuts] Re: go 1.13 won't compile

[Dmitry Savintsev]

> I do not have, need or use a go.mod. 

I would still recommend to give it a try - it will likely make your Go dev 
life easier :)
Try to follow this recipe - you probably don't need to understand much of 
what's going on "up front" to get your code to build/test:

* assuming your Github / Gitlab etc. username is 'robs', create a directory 
outside of GOPATH: mkdir -p ~/dev/robs/dsrt
* copy all your code/files from the current place to under ~/dev/robs/dsrt
* cd ~/dev/robs/dsrt
* go mod init github.com/robs/dsrt (or "gitlab.com/robs/dsrt" etc.)  // 
this should create a go.mod file
* go install -v ./...
* go test -v ./...

See if it works for you, and if not, feel free to share what errors you get.


On Sunday, September 22, 2019 at 6:56:47 PM UTC+2, rob wrote:
>
> Hi.  I think I'm having an issue compiling my code w/ go 1.13.  I have 
> not had any issues up until now.  I have my code in the default 
> locations off of ~/go/src w/ a directory for each little bit of code I 
> wrote. 
>
> Running under linuxmint 19.2 amd64, I installed the go binary by first 
> nuking /usr/local/go, and then 
>
>  sudo tar -C /usr/local -xf go1.13.linux-amd64.tar.gz. 
>
> When I run go version, I get go version go1.13 linux/amd64 
>
> Now when I run 
>
>  go install dsrt 
>
> I'm getting an error message: 
>
>  can't load package: package dsrt: mallformed module path "dsrt" : 
> missing dot in first path element. 
>
> I do not have, need or use a go.mod.  In fact, I don't really understand 
> them.  And I don't yet understand what vendoring means. 
>
> As an aside, I also compile on a win10 amd64 computer.  I installed 
> windows binary in the usual way on that computer, compiled my code using 
> go install, and I've not had any issues there.  I only have an issue 
> here on linuxmint and go 1.13. 
>
> What's up? 
>
> --rob solomon 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cb4951ef-36b9-4565-9535-8026667f7bfa%40googlegroups.com.

[go-nuts] Dependency injection in gorillamux handlers

[Nathanael Curin]

Hi everyone,

I'm currently using the gorilla/mux package to make an API with a few 
handlers that depend on multiple external resources (a Redis DB for 
example). The fact is, HTTP Handlers only use http.ResponseWriter and 
*http.Request as parameter, so I used some random dependency injection 
pattern I've found online.

The structure of my project goes as follows :
- subpackage "contact" containing the HTTP Handler as well as the Inject 
method shown below
- subpackage "config" containing a goroutine using fsnotify+mutex to 
refresh internal configuration if modified + an opened connection to a 
*redis.Client
- subpackage "mapping" which handles other files on the system in the same 
way as Config ; updates an internal map[] with new data
- subpackage "contents", same idea, mysql data source to refresh a map 
every once in a while

Here's a few code showing the current flow :

*- Router initialization :*

myRouter.Handle("/endpoint1/", contact.Inject(config.GetRedisDb(), 
contents.GetUpdater(), mapping.GetUpdater(), 
contact.Handle)).Methods("POST", "OPTIONS")

*- contact.Inject code :*

func Inject(
red *redis.Client,
u *content.Updater,
m *mapping.Updater,
f func(red *redis.Client, u *content.Updater, mapper *mapping.Updater, 
w http.ResponseWriter, r *http.Request),
) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
f(red, u, m, w, r)
})
}

*- contact.Handle signature :*

func Handle(rdsClient *redis.Client, u *content.Updater, m 
*mapping.Updater, w http.ResponseWriter, r *http.Request) {}

My issue is that the code feels quite "heavy". It works quite well and I'm 
pretty sure performance impact is quite minimal by injecting resources this 
way, but readability is quite bad, and now that I actually need to add a 
completely new dependency, I'm not sure I want to keep doing this.

Is there any better way you guys know of? Is my method being annoying to 
read through still considered as good?

Thanks!

Nathanael




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e181bdbf-8fc9-49c9-9053-7e9c24d48602%40googlegroups.com.