Re: [go-nuts] Managing perpetually running goroutines

[Sanyia Saidova]

Awesome, thanks so much for the help here! Learned a lot from the input and
code examples. :)

Much appreciated!

On Thu, 2 Sep 2021, 15:49 Bryan C. Mills,  wrote:

> On Wed, Sep 1, 2021 at 5:55 PM  wrote:
>
>> Thanks Bryan, especially for the code example.
>>
>>
>> Would using a sync.WaitGroup in place of the `done` channel in your
>> example be overkill? Just exploring what’s possible here for my own
>> education.
>>
>
> Using a `sync.WaitGroup` in place of the `done` channel would be correct,
> but perhaps less useful: it's about the same amount of code, but you can
> `select` on the channel but not on the WaitGroup.
>
> (That said, a WaitGroup *would* avoid a pointer indirection: channels are
> reference types, whereas WaitGroups are value types. That difference is the
> motivation behind my proposal in https://golang.org/issue/28366.)
>
>

-- 
You received this message because you are subscribed to the Google 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/CAChppvka_ud8h%2BUba0z7qP2ANescD3QTh5HB-LJu4i1fydiLKQ%40mail.gmail.com.

[go-nuts] Re: Printing a slice of structs recursively

[Michael Ellis]

Here's one way. https://goplay.space/#5KzrUc0171N

On Thursday, September 2, 2021 at 1:03:48 AM UTC-4 seank...@gmail.com wrote:

> Try doing it recursively, passing in both the current parent id and 
> indentation level
>
> On Thursday, September 2, 2021 at 3:55:01 AM UTC+2 n.erde...@gmail.com 
> wrote:
>
>> i need some help with printing a slice of structs which there is a child 
>> - parent relation in the struct.
>> *type* Emp *struct* {
>> id   int
>> name string
>> parentID int
>> }
>> probably the best way to do it recursively but i couldnt manage to do
>> https://play.golang.org/p/jHcbu3uBgOD
>
>

-- 
You received this message because you are subscribed to the Google 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/ae9b334a-67ab-4e5a-a1a6-a4e2a996a3ebn%40googlegroups.com.

[go-nuts] Why don't we have to use 'std' as the module prefix for packages from the standard library?

[Connor Kuehl]

I'm trying to wrap my head around modules.

When importing other packages into my project, there is a module prefix.

For example,

import (
"example.com/potato/tomato"
)

will import the "tomato" package from the "example.com/potato" module.

But this whole time as I've been learning the language, the standard
packages can be imported without any explicit prefix:

import "fmt"

and I found a go.mod in my Go distribution's standard library [1], so
that suggests to me that the standard library is implemented as a module
too.

Why don't I have to supply a prefix for the standard library packages?
Is this just a special case?

[1] https://cs.opensource.google/go/go/+/refs/tags/go1.17:src/go.mod

-- 
You received this message because you are subscribed to the Google 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/CDZT5VHC8FPS.15X2FMP9LEQ2S%40gilgalad.local.

[go-nuts] Building Better MVPs in Go

[hatchpad]

We spoke with Frankie Nicoletti, Head of Engineering at Zero Grocery, about 
common mistakes that software engineers make when jumping into Go and 
highlights the importance of using strong organizational structures when 
designing and scaling MVPs. 

In particular, she covers:

·   How you should structure your file directory

·   How you should define your models

·   How you should use interfaces

·   How to separate concerns

·   When you should utilize concurrency

·   How to scale your MVP

 

Check out her entire talk here: https://youtu.be/N1VG18S1O-A 

-- 
You received this message because you are subscribed to the Google 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/1df26892-7cd6-4ec0-8dfa-2224a4a423a3n%40googlegroups.com.

Re: [go-nuts] Re: fonts, bitmap and the (old TeX) PK file format

[Andy Balholm]

You don't need a full PostScript interpreter to use a Type 1 font. They 
use a very limited subset of PS.


To embed one in a PDF, I don't think you need to parse it at all, if you 
know the metrics and the encoding already. You can just embed it as a 
binary blob, if I'm not mistaken.


Andy

On 9/1/21 1:01 PM, 'Sebastien Binet' via golang-nuts wrote:

Howard,

On Wed Sep 1, 2021 at 18:11 CET, Howard C. Shaw III wrote:

You would implement the Face interface to have your fonts available to
Go's
text drawing routines. You can try using basicfont directly, however it
is
fixedwidth only. But just implementing the interface does not seem that
onerous.

Have a look at https://github.com/hajimehoshi/bitmapfont for an example
of
implementing Face for a mostly fixed-size bitmap font (by the author of
the
Ebiten game engine). hajimehoshi's file gives an example of dealing with
a *mostly* fixed width file, where certain characters (i.e. East Asian
glyphs) can be double-width.

Also https://github.com/textmodes/font

Not https://github.com/usedbytes/fonts - this one does not implement the
Face interface.

thanks for these pointers.
I'll have a look.
(funny my 'bitmap' queries on pkg.go.dev didn't turn them out)


However, while that would gain interoperability of your PK fonts with
Go's
text flow engine isn't TeX emulation pretty much going to require
you
roll your own text flow engine anyway? I mean, that is kind of the heart
of
TeX, using font metrics to flow text. And so in that case, looking at
https://github.com/usedbytes/fonts, which ignores the Face and golang
Font
and rolls its own text flow for rendering bitmap fonts onto Images might
actually be a useful example but only so far, because I believe it
also
assumes a fixed width font.

yes, TeX has its own set of text shaping algorithms.

in view of being able to display LaTeX equations in Gonum plots, I had
first tried to implement the "matheq" subset of LaTeX:

- https://github.com/go-latex/latex

but, in the end, I went with implementing the full kaboodle:

- https://star-tex.org
- https://star-tex.org/x/tex


And no form of fixed width font handling is going to suffice to mimic
TeX;
but again, really, with TeX what you need to be parsing from the .pk
file
is the font metrics, really. TeX never cared about the glyphs. That is
why
TeX's output was a DVI (DeVice Independent) file that had to be combined
with font files to render an actual printable or viewable output. Except
that I don't know that the PK file even has the font metrics - I think
back
then they were in a separate .tfm file?

correct.


This is relevant because one of the important elements that TeX handled
was
the concept that glyphs, properly kerned, can *overlap*. That you cannot
use the width of the glyph to know how far to move forward to draw the
next
one - that was a separate metric. (Not saying it was the first, just
that
it is one of the important features.)

Again, not to take anything away from having success parsing the .pk
file
format - kudos to you. I'm just not sure not only whether it will
actually
be helpful in emulating TeX, but whether it is even needed.
Theoretically,
you should be able to fully emulate TeX in processing a TeX-format file
into a DVI without ever touching any font glyphs at all, just the
metrics.

yes, DVI is the main output of "old" TeX (nowadays, most TeX engines
directly produce PDFs), with only the "boxes" of the glyphs (using the
TFM data.)
it's only when one issues, say, "dvipdf" that the "bounding boxes" of
each glyph is filled with the actual glyph, drawn from PK fonts (in the
very old days), from Type-1 or TTF fonts.

I have the pure-Go TeX engine that produces a .dvi from a .tex file.
now, with either PK or Type-1 fonts, I'd like to implement a "dvipng"
or "dvipdf" command; hence my query about PK fonts.
(probably the PK fonts will only be workable w/ the "dvipng" command)

Implementing support for Type-1 fonts is quite a bigger toll, as this
means implementing a PostScript interpreter.

Eventually, I'd like to implement a Gio-based viewer for DVI files.

Lots of fun ahead :)

Thanks again for the pointers.

-s



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

Re: [go-nuts] Makefiles for Go Programs

[Roland Müller]

Hello,

A big thank you to everybody who contributed to this thread! I guess it
will take some time to process the things learned from this discussion.

BR,
Roland


Am Mi., 25. Aug. 2021 um 12:28 Uhr schrieb Stephen Illingworth <
stephen.illingwo...@gmail.com>:

> I use Makefiles with Go projects. For many of the reasons already given
> but it's especially useful for me for cross compilation to the target
> platforms at release time. So, when running "make release" I have "test"
> and "generate" targets as dependencies to make sure I've not missed
> anything.
>
> I don't need a build system to do that but it's good to have a script for
> that kind of thing, IMO.
>
> I also use it in the git pre-commit hook. For example, I have "make lint"
> in that script which runs whatever linter I'm using at the moment and I can
> be assured that it's the same linter I'm using at the command line.
>
> As for why not another build system, for the same reason as other
> respondents have said. Make has been around forever and I don't need
> anything more sophisticated.
>
> > Make does not come alone for end-users. Usually it comes bundled with
> several hundreds of megabytes of > the devel packages  user gets after
> issuing eg. `sudo apt-get install build-essential`.
>
> Surely, you would just do: `sudo apt-get install make`
>
>
> On Tuesday, 24 August 2021 at 12:14:50 UTC+1 ohir wrote:
>
>> Dnia 2021-08-24, o godz. 07:54:35
>> Reto  napisał(a):
>>
>> > It may be nicer, however the beauty of make is that it is ubiquitous,
>> > everybody already has it.
>>
>> No, not everybody has it. Esp. on Windows host.
>>
>> > With mage, your installation instructions now need to contain how /
>> > where to get mage in the first place, leaving the user with a random
>> > binary somewhere which they probably never ever need nor update again.
>>
>> Nope. If user is going to compile from sources she also needs to install
>> Go compiler and tools. Once she has it the mage is a `go install` command
>> away. Shorter than typical line of "prerequisites" needed by non-developer
>> user on most of linux distros. (If she is about to install binary she does
>> not need mage at all - 99% deployments of Go based apps are just the single
>> executable.)
>>
>> > leaving the user with ... they probably never ever need nor update
>> again.
>>
>> Make does not come alone for end-users. Usually it comes bundled with
>> several hundreds of megabytes of the devel packages
>> user gets after issuing eg. `sudo apt-get install build-essential`. Then
>> she's left with a bit more more unused stuff than a single
>> mage binary.
>>
>> TC,
>>
>> --
>> Wojciech S. Czarnecki
>> << ^oo^ >> OHIR-RIPE
>>
> --
> You received this message because you are subscribed to the Google 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/039b0cac-a81c-40ae-bb46-f12d11261707n%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/CA%2B8p0G0vb6RbwP4cQ3yNHk%3DGY%2BFW9Frx3e-M24vifW8QPsOn9g%40mail.gmail.com.

Re: [go-nuts] Where to copy vendor to the go docker builder?

[Chris Burkert]

Would it help to set up your own module proxy e.g. with
https://github.com/gomods/athens or
https://github.com/goproxy/goproxy?

K Prayogo  schrieb am Do. 2. Sept. 2021 um 03:54:

> I'm trying to make docker build faster for software that are built with
> golang
> tried to cache layer but it still slow when dependency changed since go
> mod download have to redownload whole dependency again and again.
>
> how to make use vendor directory on docker  build? (where to copy? so go
> build or go mod download/go mod vendor inside Dockerfile so it doesn't
> redownload agian and again)?
> I've tried to copy whole vendor, but it still redownloading
> tried to copy vendor to $GOPATH/pkg/mod, but it also still redownloading
> tried to copy vendor to $GOPATH/pkg/mod/cache/download, but it still
> redownloading
> where the correct way to put vendor directory?
>
>
> https://stackoverflow.com/questions/69020535/how-to-prevent-docker-build-from-redownloading-copied-golang-vendor
>
> --
> You received this message because you are subscribed to the Google 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/a377ced9-16ce-4862-9478-70c2b10b4280n%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/CALWqRZqfOLTxCg7_KVK4UevXoj6SP5-Vx4gc%2BK7F8itQRGYN7Q%40mail.gmail.com.

Re: [go-nuts] HTTP request matching different endpoint - gorilla mux

[Van Fury]

Thank you for your answer. Very helpful. 

On Thursday, September 2, 2021 at 8:01:54 PM UTC+3 seank...@gmail.com wrote:

> gorilla/mux tests routes in the order they're added.
> You can register your shared_data route before the {id} one if you must 
> keep the ambiguous path,
> though the better option is to not have ambiguous paths in the first place.
>
> On Thursday, September 2, 2021 at 6:18:36 PM UTC+2 bse...@computer.org 
> wrote:
>
>> Your paths are ambiguous.  "/nfdm-fdm/v2/shared-data" matches  
>> "/nfdm-fdm/v2/{id}" where id=shared_data. You can use a regex for the path 
>> with {id} to exclude the "shared_data" match.
>>
>> On Thu, Sep 2, 2021 at 10:13 AM Van Fury  wrote:
>>
>>> Hi All,
>>>
>>> I have the following to handler functions, DataSetsGet and 
>>> RetrieveSharedData.
>>> When make request with the URL 
>>> https://127.0.0.1:2/nfdm-fdm/v2/shared-data, I get response from 
>>> DataSetsGet handler instead of RetrieveSharedData handler function. When I 
>>> take the bracket from {id} to id, I get the right response from 
>>> RetrieveSharedData handler. Any help to solve this issue, my code below 
>>> with omitted codes.
>>>
>>> ```
>>> func DataSetsGet(response http.ResponseWriter, request *http.Request) {
>>>
>>> // Data set response codes
>>> }
>>>
>>> func RetrieveSharedData(response http.ResponseWriter, request 
>>> *http.Request) {
>>> // Retrieve shared data response codes
>>> }
>>>
>>>
>>>
>>> type Route struct {
>>> Namestring
>>> Method  string
>>> Pattern string
>>> HandlerFunc http.HandlerFunc
>>> }
>>>
>>> var Router = NewRouter()
>>>
>>> type Routes []Route
>>>
>>> func NewRouter() *mux.Router {
>>> router := mux.NewRouter().StrictSlash(true)
>>> for _, route := range routes {
>>> var handler http.Handler
>>> handler = route.HandlerFunc
>>>
>>> router.
>>> Methods(route.Method).
>>> Path(route.Pattern).
>>> Name(route.Name).
>>> Handler(handler)
>>> }
>>>
>>> return router
>>> }
>>>
>>>
>>> var routes = Routes{
>>> Route{
>>> "DataSetsGet",
>>> strings.ToUpper("Get"),
>>> "/nfdm-fdm/v2/{id}",
>>> DataSetsGet,
>>> },
>>>
>>> Route{
>>> "RetrieveSharedData",
>>> strings.ToUpper("Get"),
>>> "/nfdm-fdm/v2/shared-data",
>>> RetrieveSharedData,
>>> },
>>>
>>> }
>>>
>>>
>>> func main{
>>>
>>> addr := "127.0.0.1:6060"
>>>
>>> server := NewServer(addr)
>>>
>>> go func() {
>>> err := server.ListenAndServe() 
>>> if err != nil && err != http.ErrServerClosed {
>>> logger.Log.Errorf("Could not listen on %s: %v\n", addr, err)
>>> }
>>> }()
>>> }
>>>
>>>
>>>
>>> // Create a new server
>>> func NewServer(ListAddr string) *http.Server {
>>>
>>> return {
>>> Addr: ListAddr,
>>> Handler:  Router,
>>> ReadTimeout:  5 * time.Second,
>>> WriteTimeout: 10 * time.Second,
>>> IdleTimeout:  15 * time.Second,
>>> }
>>> }
>>> ```
>>>
>>> BR
>>> Fury
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/faf2c214-3638-4b3e-b460-1a789e351defn%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/5fb6fbe9-3414-4c10-9318-f300ac71873cn%40googlegroups.com.

Re: [go-nuts] HTTP request matching different endpoint - gorilla mux

[Sean Liao]

gorilla/mux tests routes in the order they're added.
You can register your shared_data route before the {id} one if you must 
keep the ambiguous path,
though the better option is to not have ambiguous paths in the first place.

On Thursday, September 2, 2021 at 6:18:36 PM UTC+2 bse...@computer.org 
wrote:

> Your paths are ambiguous.  "/nfdm-fdm/v2/shared-data" matches  
> "/nfdm-fdm/v2/{id}" where id=shared_data. You can use a regex for the path 
> with {id} to exclude the "shared_data" match.
>
> On Thu, Sep 2, 2021 at 10:13 AM Van Fury  wrote:
>
>> Hi All,
>>
>> I have the following to handler functions, DataSetsGet and 
>> RetrieveSharedData.
>> When make request with the URL 
>> https://127.0.0.1:2/nfdm-fdm/v2/shared-data, I get response from 
>> DataSetsGet handler instead of RetrieveSharedData handler function. When I 
>> take the bracket from {id} to id, I get the right response from 
>> RetrieveSharedData handler. Any help to solve this issue, my code below 
>> with omitted codes.
>>
>> ```
>> func DataSetsGet(response http.ResponseWriter, request *http.Request) {
>>
>> // Data set response codes
>> }
>>
>> func RetrieveSharedData(response http.ResponseWriter, request 
>> *http.Request) {
>> // Retrieve shared data response codes
>> }
>>
>>
>>
>> type Route struct {
>> Namestring
>> Method  string
>> Pattern string
>> HandlerFunc http.HandlerFunc
>> }
>>
>> var Router = NewRouter()
>>
>> type Routes []Route
>>
>> func NewRouter() *mux.Router {
>> router := mux.NewRouter().StrictSlash(true)
>> for _, route := range routes {
>> var handler http.Handler
>> handler = route.HandlerFunc
>>
>> router.
>> Methods(route.Method).
>> Path(route.Pattern).
>> Name(route.Name).
>> Handler(handler)
>> }
>>
>> return router
>> }
>>
>>
>> var routes = Routes{
>> Route{
>> "DataSetsGet",
>> strings.ToUpper("Get"),
>> "/nfdm-fdm/v2/{id}",
>> DataSetsGet,
>> },
>>
>> Route{
>> "RetrieveSharedData",
>> strings.ToUpper("Get"),
>> "/nfdm-fdm/v2/shared-data",
>> RetrieveSharedData,
>> },
>>
>> }
>>
>>
>> func main{
>>
>> addr := "127.0.0.1:6060"
>>
>> server := NewServer(addr)
>>
>> go func() {
>> err := server.ListenAndServe() 
>> if err != nil && err != http.ErrServerClosed {
>> logger.Log.Errorf("Could not listen on %s: %v\n", addr, err)
>> }
>> }()
>> }
>>
>>
>>
>> // Create a new server
>> func NewServer(ListAddr string) *http.Server {
>>
>> return {
>> Addr: ListAddr,
>> Handler:  Router,
>> ReadTimeout:  5 * time.Second,
>> WriteTimeout: 10 * time.Second,
>> IdleTimeout:  15 * time.Second,
>> }
>> }
>> ```
>>
>> BR
>> Fury
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/faf2c214-3638-4b3e-b460-1a789e351defn%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/6e0e923b-e245-4e4c-ae99-529fd2e97b38n%40googlegroups.com.

Re: [go-nuts] HTTP request matching different endpoint - gorilla mux

[burak serdar]

Your paths are ambiguous.  "/nfdm-fdm/v2/shared-data" matches
"/nfdm-fdm/v2/{id}" where id=shared_data. You can use a regex for the path
with {id} to exclude the "shared_data" match.

On Thu, Sep 2, 2021 at 10:13 AM Van Fury  wrote:

> Hi All,
>
> I have the following to handler functions, DataSetsGet and
> RetrieveSharedData.
> When make request with the URL
> https://127.0.0.1:2/nfdm-fdm/v2/shared-data, I get response from
> DataSetsGet handler instead of RetrieveSharedData handler function. When I
> take the bracket from {id} to id, I get the right response from
> RetrieveSharedData handler. Any help to solve this issue, my code below
> with omitted codes.
>
> ```
> func DataSetsGet(response http.ResponseWriter, request *http.Request) {
>
> // Data set response codes
> }
>
> func RetrieveSharedData(response http.ResponseWriter, request
> *http.Request) {
> // Retrieve shared data response codes
> }
>
>
>
> type Route struct {
> Namestring
> Method  string
> Pattern string
> HandlerFunc http.HandlerFunc
> }
>
> var Router = NewRouter()
>
> type Routes []Route
>
> func NewRouter() *mux.Router {
> router := mux.NewRouter().StrictSlash(true)
> for _, route := range routes {
> var handler http.Handler
> handler = route.HandlerFunc
>
> router.
> Methods(route.Method).
> Path(route.Pattern).
> Name(route.Name).
> Handler(handler)
> }
>
> return router
> }
>
>
> var routes = Routes{
> Route{
> "DataSetsGet",
> strings.ToUpper("Get"),
> "/nfdm-fdm/v2/{id}",
> DataSetsGet,
> },
>
> Route{
> "RetrieveSharedData",
> strings.ToUpper("Get"),
> "/nfdm-fdm/v2/shared-data",
> RetrieveSharedData,
> },
>
> }
>
>
> func main{
>
> addr := "127.0.0.1:6060"
>
> server := NewServer(addr)
>
> go func() {
> err := server.ListenAndServe()
> if err != nil && err != http.ErrServerClosed {
> logger.Log.Errorf("Could not listen on %s: %v\n", addr, err)
> }
> }()
> }
>
>
>
> // Create a new server
> func NewServer(ListAddr string) *http.Server {
>
> return {
> Addr: ListAddr,
> Handler:  Router,
> ReadTimeout:  5 * time.Second,
> WriteTimeout: 10 * time.Second,
> IdleTimeout:  15 * time.Second,
> }
> }
> ```
>
> BR
> Fury
>
> --
> You received this message because you are subscribed to the Google 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/faf2c214-3638-4b3e-b460-1a789e351defn%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/CAMV2RqqU3bTZ3midOUr1Dn8Aax0wdgSABmrPrOOfSv%2B252YqRg%40mail.gmail.com.

[go-nuts] HTTP request matching different endpoint - gorilla mux

[Van Fury]

Hi All,

I have the following to handler functions, DataSetsGet and 
RetrieveSharedData.
When make request with the URL 
https://127.0.0.1:2/nfdm-fdm/v2/shared-data, I get response from 
DataSetsGet handler instead of RetrieveSharedData handler function. When I 
take the bracket from {id} to id, I get the right response from 
RetrieveSharedData handler. Any help to solve this issue, my code below 
with omitted codes.

```
func DataSetsGet(response http.ResponseWriter, request *http.Request) {

// Data set response codes
}

func RetrieveSharedData(response http.ResponseWriter, request 
*http.Request) {
// Retrieve shared data response codes
}



type Route struct {
Namestring
Method  string
Pattern string
HandlerFunc http.HandlerFunc
}

var Router = NewRouter()

type Routes []Route

func NewRouter() *mux.Router {
router := mux.NewRouter().StrictSlash(true)
for _, route := range routes {
var handler http.Handler
handler = route.HandlerFunc

router.
Methods(route.Method).
Path(route.Pattern).
Name(route.Name).
Handler(handler)
}

return router
}


var routes = Routes{
Route{
"DataSetsGet",
strings.ToUpper("Get"),
"/nfdm-fdm/v2/{id}",
DataSetsGet,
},

Route{
"RetrieveSharedData",
strings.ToUpper("Get"),
"/nfdm-fdm/v2/shared-data",
RetrieveSharedData,
},

}


func main{

addr := "127.0.0.1:6060"

server := NewServer(addr)

go func() {
err := server.ListenAndServe() 
if err != nil && err != http.ErrServerClosed {
logger.Log.Errorf("Could not listen on %s: %v\n", addr, err)
}
}()
}



// Create a new server
func NewServer(ListAddr string) *http.Server {

return {
Addr: ListAddr,
Handler:  Router,
ReadTimeout:  5 * time.Second,
WriteTimeout: 10 * time.Second,
IdleTimeout:  15 * time.Second,
}
}
```

BR
Fury

-- 
You received this message because you are subscribed to the Google 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/faf2c214-3638-4b3e-b460-1a789e351defn%40googlegroups.com.

Re: [go-nuts] Managing perpetually running goroutines

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

On Wed, Sep 1, 2021 at 5:55 PM  wrote:

> Thanks Bryan, especially for the code example.
>
>
> Would using a sync.WaitGroup in place of the `done` channel in your
> example be overkill? Just exploring what’s possible here for my own
> education.
>

Using a `sync.WaitGroup` in place of the `done` channel would be correct,
but perhaps less useful: it's about the same amount of code, but you can
`select` on the channel but not on the WaitGroup.

(That said, a WaitGroup *would* avoid a pointer indirection: channels are
reference types, whereas WaitGroups are value types. That difference is the
motivation behind my proposal in https://golang.org/issue/28366.)

-- 
You received this message because you are subscribed to the Google 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/CAKWVi_TPDpinBfzNW8w%3Dd6R-whQPm%3DLhjT%2B_tZCQS0hAY2Nu6w%40mail.gmail.com.

Re: [go-nuts] pkg.go.dev: navigation index is confusing

['Axel Wagner' via golang-nuts]

On Thu, Sep 2, 2021 at 12:26 PM Markus Heukelom 
wrote:

> So, turns out, the function is actually listed under the type "Handler",
> probably because it implements that interface.
>

Because it returns that type. It's a heuristic to find "constructors" of
types, which is useful if you know you want that type and want to know how
to get one.

That's helpful indeed if you are interested to see which types implement
> "Handler" (even though the index does not state that "Handler" is an
> interface so you first wonder 1 minute why "Handler" has types hanging
> under it instead of methods, but ok).
>

To be clear, a function doesn't "implement" an interface. Only types do.
And there is no association (neither in the language, nor the docs) between
a type and the interfaces it implements. The association between the type
and its constructors is, however, independent of whether that type is an
interface or a concrete type.

However, the *primary* use of the index is to *quickly* find that function
> you're looking for.  That's what indexes are for.
>

I don't agree with the premise that "I want to find the function" is
inherently more useful than "I want to see how to get this type". I also
wouldn't claim it's *less* useful. Both are very useful, depending on what
you want.

Personally, if I already know what function I'm looking for, I use Ctrl+F
and my browsers search function instead. And I find it far more often
useful to be able to quickly see how I'm intended to construct a certain
type (without knowing the name of the function to do so).



>
> Another example is the x/net/html package.
>
> The "Parse" function is arguably the most important function of the whole
> package. Well - you can only find Parse *under* the Node type, which is by
> default collapsed.
>

> Another fun example is the documentation for type http.FileSystem. It
> contains this text:
>
> "See the FileServer function to convert a FileSystem to a Handler."
>
> Awesome! Let's look up that FileServer function in the index.
>
> Well. It's not there.
>
> No.
>
> You are expected to be so smart to realise that FileServer of course
> implements the Handler interface and is therefore only listed under the
> collapsed Handler type. Maddening.
>
> Proposal: just list all functions in the index please.
>
> NOTE: I admire Go & Go.dev. My exaggerative style is just used to
> illustrate my point.
>
> NOTE: My apologies if this is not the place for go.dev feedback. Please
> redirect me.
>
> NOTE: I know that the index in the old package docs also has this
> structure. It has somewhat the same issue, but at least you could scroll
> through it a scan for function  names.
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google 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/15cb6bbd-83fc-44f7-a5fc-a922b7112461n%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/CAEkBMfHnhKmva19Bf1z%2BEiBzJ5aEoE_ibeuBsrShhQmGzxpb%2Bw%40mail.gmail.com.

[go-nuts] pkg.go.dev: navigation index is confusing

[Markus Heukelom]

The main issue is that most package functions are not actually listed under 
"Functions". 

For example, I wanted to lookup StripPrefix in the http package. I could 
not find it in the package documentation function index. It was not there. 

So I looked under Types (maybe I did remember it incorrectly?). It wasn't 
listed there either. 

But I was quite sure it existed. 

I eventually found it using the Jump-To bar.

So, turns out, the function is actually listed under the type "Handler", 
probably because it implements that interface. 

Well. Cool.  

That's helpful indeed if you are interested to see which types implement 
"Handler" (even though the index does not state that "Handler" is an 
interface so you first wonder 1 minute why "Handler" has types hanging 
under it instead of methods, but ok).

However, the *primary* use of the index is to *quickly* find that function 
you're looking for.  That's what indexes are for.Turns out, it just 
only lists like half of the functions - if you're lucky.

Another example is the x/net/html package. 

The "Parse" function is arguably the most important function of the whole 
package. Well - you can only find Parse *under* the Node type, which is by 
default collapsed.

Another fun example is the documentation for type http.FileSystem. It 
contains this text:

"See the FileServer function to convert a FileSystem to a Handler." 

Awesome! Let's look up that FileServer function in the index.

Well. It's not there.

No. 

You are expected to be so smart to realise that FileServer of course 
implements the Handler interface and is therefore only listed under the 
collapsed Handler type. Maddening.

Proposal: just list all functions in the index please.

NOTE: I admire Go & Go.dev. My exaggerative style is just used to 
illustrate my point.

NOTE: My apologies if this is not the place for go.dev feedback. Please 
redirect me.

NOTE: I know that the index in the old package docs also has this 
structure. It has somewhat the same issue, but at least you could scroll 
through it a scan for function  names.







 

-- 
You received this message because you are subscribed to the Google 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/15cb6bbd-83fc-44f7-a5fc-a922b7112461n%40googlegroups.com.