Re: [go-nuts] circular package dependency between golang.org/x/mod and golang.org/x/tools

[Nathan Lacey]

My main concern is if you do a go mod graph of applications that import  
these packages, you see references to old libraries, libraries that have 
security vulnerabilities.

On Tuesday, December 19, 2023 at 5:49:05 PM UTC-5 Rob Pike wrote:

> If it's only in the test, the circularity only arises when testing both 
> packages in a single build. That doesn't happen so is not a problem at all, 
> and in fact the stdlib is full of such circularities involving common 
> packages like fmt.
>
> -rob
>
>
>
> On Wed, Dec 20, 2023 at 7:49 AM Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Tue, Dec 19, 2023 at 9:37 PM Nathan Lacey  
>> wrote:
>>
>> > I noticed that we have a circular dependency between golang.org/x/mod 
>> and golang.org/x/tools
>> >
>> >  golang.org/x/mod  zip/zip_test.go includes golang.org/x/tools
>> > I think we could get rid of the circular package dependency by changing 
>> that unit test to remove the dependency to tools/txtar .
>>
>> But why? What's the motivation to remove the cycle?
>>
>> -- 
>> You received this message because you are subscribed 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/CAA40n-URNGfDo34j4Ui-wvCiYjQysfMoJii%2B1m3CP_U85c0ezA%40mail.gmail.com
>> .
>>
>

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

[go-nuts] circular package dependency between golang.org/x/mod and golang.org/x/tools

[Nathan Lacey]

I noticed that we have a circular dependency between golang.org/x/mod and 
golang.org/x/tools

 golang.org/x/mod  zip/zip_test.go includes golang.org/x/tools
I think we could get rid of the circular package dependency by changing 
that unit test to remove the dependency to tools/txtar .

-- 
You received this message because you are subscribed to the Google 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/f60e4010-824e-4792-be33-6596601ffa8en%40googlegroups.com.

Re: [go-nuts] Is this algorithm viable? its faster than AES256 upto 50KB

[Nathan Fisher]

When looking at hashing algorithms there's a whole lot of factors to
consider.

A few of the common considerations are:

1. performance.
2. cryptographic or not.
3. collision rate including avalanche effect and bit-size.

There are a bunch of other considerations but those are some high-level
concerns that will often come up when considering a hash function. In the
case of AES256 it is a cryptographically secure algorithm which often
implies a tradeoff in performance. Depending on your needs an alternative
algorithm might be more appropriate such as FNV (available in stdlib),
murmur, CityHash, etc that aren't cryptographically secure but provide
generally good hashing properties in terms of collision rate and
performance.

Cheers,
Nathan


On Tue, Aug 2, 2022 at 7:32 PM Alex Breadman  wrote:

> package mod
>
> import (
> "testing"
> )
>
> func TestEncrypt(t *testing.T) {
> password := []byte("*RTFUGIHOD&TUGGIYKl")
> data := []byte("This encryption algorithm is faster than aes256 up to 40kb
> but how secure is it?")
> for x, _ := range data {
> p := (password[x%len(password)])
> data[x] = data[x] + byte(p)
> }
> println(string(data))
> for x, _ := range data {
> p := (password[x%len(password)])
> data[x] = data[x] - byte(p)
> }
> println(string(data))
> }
>
> Surely it is only as strong as the password?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1c8a67cb-d7da-4c41-a8c5-92727d24e773n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/1c8a67cb-d7da-4c41-a8c5-92727d24e773n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Nathan Fisher
 w: http://junctionbox.ca/

-- 
You received this message because you are subscribed to the Google 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%2Bc2dWfg%3DuhL7FPeHq54QjtvRwf%3DPN-UaC1E2%3DHmYrTC_ENCpQ%40mail.gmail.com.

Re: [go-nuts] Thread safe tree library?

[Nathan Fisher]

I was thinking of potential issues if you rebalance the tree as an example.

I’m not certain what issues could arise as I’ve never considered a
concurrent data structure that lacks some kind of synchronisation for both
read and writes unless it’s immutable copy-on-write or similar.

Do you happen to have references available for further research?

On Tue, Jan 5, 2021 at 20:15, K. Alex Mills  wrote:

> On Tue, Jan 5, 2021, 6:59 PM Nathan Fisher  wrote:
>
>> Does write only locking provide read correctness? I would’ve thought
>> based on the memory model it could cause issues?
>>
>> https://golang.org/ref/mem#tmp_2
>>
>
> It depends on your notion of "read correctness", specifically when you
> consider each read to have occurred with respect to its concurrent writes.
> Linearizability may be a weaker guarantee than you want, and that's okay.
>
> Linearizability requires that, for each operation, you can pick some point
> between the start and end of an operation when it can be said to have
> "occurred". When you consider all the operations in that order, the results
> you see must be the same as a sequential execution.
>
> In the case I have described, we can pick a linearization point for reads
> just before the last write which they passed on their way down the tree.
> The reads should then see all the writes which happened prior to this point.
>
> This isn't the order the operations enter the root, but linearizability
> doesn't care. It doesn't have an opinion on when overlapping operations
> "occur" with respect to one another.
>
> I don't think using a happens-before relation for the program order seen
> by each goroutine is going to cause a problem with respect to choosing
> these linearization points, but maybe I'm missing something.
>
> Maybe also there is a standardized notion of read correctness that you're
> referring to which I am not aware of.
>

-- 
You received this message because you are subscribed to the Google 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%2Bc2dWexae8DOR4h4M9hgCFps%3D60F7bjr%3DKGPLS3OuvTL-NN7w%40mail.gmail.com.

Re: [go-nuts] Thread safe tree library?

[Nathan Fisher]

Does write only locking provide read correctness? I would’ve thought based
on the memory model it could cause issues?

https://golang.org/ref/mem#tmp_2


On Tue, Jan 5, 2021 at 19:40, K. Alex Mills  wrote:

> That is the simplest and most conservative way go about it, but ultimately
> it depends on what you need out of your concurrency semantics.
>
> If you're willing to settle for a linearizable execution, you can gain
> some performance improvements by only checking the lock for write
> operations. So long as two write operations do not pass each other in the
> tree, they will be linearizable based on which write passed the root node
> first. Read operations can pass one another (and other write operations)
> freely. We can always pick a linearization point for them with respect to
> the rest of the concurrent write operations in the tree.
>
> You will also need to do hand-over-hand locking on your way down the tree
> to ensure no two writes can overtake one another.
>
> An approach like this can yield significant performance gains and you can
> formally show that the results you get are correct with regard to some
> actual state the tree could be in depending on when you consider each
> concurrent write to "complete".
>
> On Tue, Jan 5, 2021, 5:53 PM joseph.p...@gmail.com <
> joseph.p.mcguc...@gmail.com> wrote:
>
>> Is there a simple tree library that is thread safe?
>>
>> If I have to write one for myself, do I have to set locks on nodes as I
>> walk the tree to
>> prevent another thread from changing nodes that are 'above' me?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/6597198c-c439-4a1e-bff2-a2176204b272n%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/CALJzkY-RSMPbObc-Dxhw985O9v_raMhGNwGcy03%3DKuWRTHeRmg%40mail.gmail.com
> 
> .
>

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

[go-nuts] Any general VPN(pptp, l2tp, openVPN, IPSec VPN) server implementation in go?

[Nathan]

Hi, I want to use a general VPN protocols to comminucate with my server, we 
cannot change the client to use other VPN protocols.
But I did a lot of research, it seems there is no go implementation for the 
general VPN.

I really want that I'm wrong, so do any guys can give me some suggestion? 
Thanks in advance.

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

Re: [go-nuts] import a file

[Nathan Fisher]

Hola!

Based on your initial project layout you have a couple of issues. When
using the legacy gopath everything should ideally live under that path.
Imports then become relative to that root.

Your main lives outside of the root which works with go run but is not how
a project should be structured.

For a small toy project I would place both files in the same directory and
set their package name to main.

If however your objective is to better understand imports then I would
reconsider your project structure. In the root directory of your project I
would place your main.go and run “go mod init” there. In that root
directory you can then create your jsonstuff directory. As an example:

project/main.go
project/go.mod
project/jsonstuff/types.go

When using go mod it typically (but not always) maps to a single
module/project/repository.

go mod init 

The module specified above is usually a URI without the protocol. By
following this practise it makes the project “go gettable”. If you maintain
src as your module name you would need to change the import for jsonstuff
to src/jsonstuff and move your main.go to the src directory.

As mentioned by others src isn’t a good name for a module. Better to do
something like:

go mod init github.com//helloworld

You would then change your jsonstuff import to:

github.com//helloworld/jsonstuff

Be aware only one package can live per directory except the special *_test
form which restricts test access to the packages public api only.

On Thu, Jul 30, 2020 at 23:55, Julian Fields 
wrote:

> Thanks Jesper and Volker.
> After reading the article(s) and go help modules and a few blogs, I still
> was not able to see why deleting go.mod makes the program import
> jsonstuff package, and compile and run?
> Modules are a great idea and I want to use them, but I can't get it to
> compile
> a "hello golang" program even:
>
> ===
> $ ls  /home/jfields/go/src/jsonstuff
> typestuff.go
> $ go mod init src
> go: creating new go.mod: module src
> $ more go.mod
> module src
>
> go 1.14
> $ go run main.go
> main.go:7:2: package jsonstuff is not in GOROOT
> (/usr/local/go/src/jsonstuff)
> $ rm go.mod
> $ go run main.go
> Hello golang
> {0}
> =
>
>
> On Thu, Jul 30, 2020 at 5:01 AM Jesper Louis Andersen <
> jesper.louis.ander...@gmail.com> wrote:
>
>> On Thu, Jul 30, 2020 at 12:54 PM Volker Dobler <
>> dr.volker.dob...@gmail.com> wrote:
>>
>>> You dop not import files and you do
>>> not run files and you do not test files. Files contain the
>>> sources but are basically uninteresting: Focus on
>>> packages (and modules).
>>>
>>
>> In Go, we disconnect the name of a file and the package in which it
>> lives. That is, the programmer is free (mostly) to choose whatever names
>> for files in a package, and also free to create as many files as is seen
>> necessary. It is in contrast to a large set of other languages, which
>> require that the package and the filename stay the same. The advantage is
>> that you can have very large packages and gracefully split them over
>> multiple files without having to resort to inventing new internal package
>> names.
>>
>> My general view is that you shouldn't assume a connection between the
>> file system and the packages of your language, and the languages which do
>> have the wrong design. However, since that "mistake" is made in many
>> languages, people tend to get somewhat confused when they encounter a
>> system where it isn't the case.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/pP-0WEpzbEs/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAGrdgiX%2BN%2BospARM7adQ1E0wk-K7M73Jbj1KEUXkxjGGq9Q9zg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX%2BN%2BospARM7adQ1E0wk-K7M73Jbj1KEUXkxjGGq9Q9zg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAAcmRO8TZ4ftK%2BFsTQTw7nEGZ0e3gFFpv5uygb4S6YavVRe_Xg%40mail.gma

Re: [go-nuts] Re: Generics and parentheses

[Nathan Bosscher]

As others have mentioned, I'm still partial to angles to represent 
generics. e.g. func Method(input Type)
I'm really glad you didn't go the round bracket method as that's super 
confusing in a method declaration.
Squares aren't horrible, but I've always associated them with indexing/key 
lookups. I definitely wouldn't prefer it.

Looking forward to getting generics in Go!

Nate

On Friday, July 17, 2020 at 12:05:41 PM UTC-4 Michael Jones wrote:

> Jon, this is a special case where a "tr '«»' '[]'' is enough.
>
> On Fri, Jul 17, 2020 at 8:56 AM Jon Conradt  wrote:
>
>> In the spirit of “show me, don’t tell me” and experience reports. How 
>> hard would it be to release a beta which supports both [] and guillamets? 
>> We try them. We see where we have compatibility problems. We give editor 
>> writers and plugin writers a chance to simplify they keystrokes?
>>
>> Jon
>>
>> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>>
>>> On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote: 
>>> > 
>>> > Guillamets are worth consideration. They are common on European 
>>> keyboards and avoid all the syntax ambiguities. 
>>>
>>>
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use
>>>  
>>>
>>> Ian 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com*
>

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

Re: [go-nuts] political fundraising on golang.org!

[Nathan Fisher]

Who knew a 50px high desktop only banner was such a usability obstacle.

On Mon, Jun 15, 2020 at 12:00 PM 'Thomas Bushnell, BSG' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'm saddened by all the snowflakes who can't handle a message they
> disagree with for a second, which is literally costing them exactly nothing.
>
> I'm also saddened by anyone who thinks the message itself is somehow
> objectionable. But I won't stop being an anti-racist just because some
> people are made uncomfortable by the fairly plain message that black lives
> matter.
>
> I'm disgusted by the dog whistles already blown on this thread.
>
> On Mon, Jun 15, 2020 at 10:27 AM Marvin Renich  wrote:
>
>> [Note To and CC]
>>
>> Please consider this a formal request for the Go Project Stewards to
>> review the website banners being discussed in this thread and to make a
>> determination that these banners are causing divisiveness in the Go
>> Community and have offended some, and that the banners' content is
>> inappropriate in this context.
>>
>> ...Marvin
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/20200615142640.2p37xxlnammendrr%40basil.wdw
>> .
>>
> --
> You received this message because you are subscribed to the Google 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%2BYjuxu%3DYzT6mWA1EtThjf8rTjMfefGmfuzYw__0LwMou4W2wQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxu%3DYzT6mWA1EtThjf8rTjMfefGmfuzYw__0LwMou4W2wQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Nathan Fisher
 w: http://junctionbox.ca/

-- 
You received this message because you are subscribed to the Google 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%2Bc2dWdg1zrJJQixjLEAv6G8pHDZJ2Zq-VDo-AwLR57zuSbtvQ%40mail.gmail.com.

Re: [go-nuts] Facebook web app and go?

[Nathan Fisher]

If you’re in AppEngine/GCP territory already there’s CloudDatastore
(NoSQL), Blockstorage, and Memcache which used to all be available in their
free tier. There’s emulators available in the gcloud tool kit that provides
a reasonable local development experience.

Cheers!
Nathan

On Mon, Apr 29, 2019 at 22:12, Miguel Angel Rivera Notararigo <
ntr...@gmail.com> wrote:

> Hi! you could use the standard library, take a look at
> https://golang.org/pkg/net/http and https://golang.org/pkg/html/template/
> packages, should be enough with them. It looks like an embedded database
> fits for your use case, you could use https://github.com/dgraph-io/badger
> or SQLite if you prefer relational databases
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Nathan Fisher
 w: http://junctionbox.ca/

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

[go-nuts] Re: Should SIGTERM be included in the os package?

[Nathan Fisher]

As an alternative should the docs be updated to use the syscall package
signals directly?
https://godoc.org/os/signal#Notify

Feels mildly strange intermixing vars from os and syscall where each has
it's own distinct convention for the signal names.

The two signals found in os follow the standard Go convention for variable
names (e.g. Interrupt). Whereas the syscall package uses a convention more
akin to C (e.g. SIGINT) presumably a result of auto-generation or legacy.

On Tue, 16 Apr 2019 at 23:36, Nathan Fisher  wrote:

> Hello,
>
> Currently the *os* package defines the following signals:
>
> var (
> Interrupt Signal <https://godoc.org/os#Signal> = syscall 
> <https://godoc.org/syscall>.SIGINT <https://godoc.org/syscall#SIGINT>
> Kill  Signal <https://godoc.org/os#Signal> = syscall 
> <https://godoc.org/syscall>.SIGKILL <https://godoc.org/syscall#SIGKILL>
> )
>
> Would it make sense to include a Term signal as well or were these signals
> considered historical accidents?
>
> My argument for including Term/SIGTERM is that it's used to notify pods of
> imminent shutdown in kubernetes.
>
> While it's simple enough to add a var to my app it feels unnecessary for
> something that seems an increasingly common signal to handle.
>
> Thoughts?
>
> Kind regards,
> --
> Nathan Fisher
>  w: http://junctionbox.ca/
>


-- 
Nathan Fisher
 w: http://junctionbox.ca/

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

[go-nuts] Should SIGTERM be included in the os package?

[Nathan Fisher]

Hello,

Currently the *os* package defines the following signals:

var (
Interrupt Signal <https://godoc.org/os#Signal> = syscall
<https://godoc.org/syscall>.SIGINT <https://godoc.org/syscall#SIGINT>
Kill  Signal <https://godoc.org/os#Signal> = syscall
<https://godoc.org/syscall>.SIGKILL
<https://godoc.org/syscall#SIGKILL>
)

Would it make sense to include a Term signal as well or were these signals
considered historical accidents?

My argument for including Term/SIGTERM is that it's used to notify pods of
imminent shutdown in kubernetes.

While it's simple enough to add a var to my app it feels unnecessary for
something that seems an increasingly common signal to handle.

Thoughts?

Kind regards,
-- 
Nathan Fisher
 w: http://junctionbox.ca/

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

Re: [go-nuts] Forking/transfering a repository and import paths

[Nathan Fisher]

TLDR

> Is it possible to fork a repo and change the import path of the
repository?

Not in one step with the github “click to fork”. You need to do one of the
following:

1. Create a new empty remote repo, remap imports, and push to the new
remote.
2. Fork, update imports, push.
3. Assuming vanity URL is used, fork and then update the vanity urls meta
tag.

> Is it possible to have:
> both repos
yes but I would try to deprecate one as “archived/historical”.

> every repo with it's own import path
yes, it does by nature of being different urls

> code exchange between them
yes, but I’d avoid if possible. You’ll need to remap imports to match the
repo so it’s not a simple push to both remotes.

—

You can use gofmt to remap the import paths. If you’re aim is to “sync”
repos (I’m not clear why you’d want this aside from a clearance process for
making corp stuff public) then you could encode the commands in a script or
make target and trigger them as part of a “publishing process”. Relative
import paths were available at one point but they are now
deprecated/unavailable. In theory it allowed ignorance of the SCMs root at
the sacrifice of not being go gettable and probably a number of other
issues which resulted in its removal.

Godoc isn’t essential infrastructure in my opinion, you can serve docs
locally in a pinch and I often do this while working offline in planes,
trains, and automobiles. Introducing a registry however adds a failure
domain/security concern that can break or be compromised. If githubs down
and your repo is on github it’s the same failure domain so you’re arguably
no worse/better off if your deps are there. Committing vendor where
possible minimises the failure domains further and generally yields faster
CI builds as a side benefit IME.

Another option might be abusing vanity urls if the objective is to support
ongoing development in both repos (eg returning different meta tags based
on a work IP vs not or a local /etc/hosts override to a different vanity
url host). I’m not terribly familiar with them but in theory it should
allow the same import path in both repos but it would likely result in some
confusing issues. I don’t think it’s a great idea but it might work for
your scenario.
On Fri, Dec 28, 2018 at 18:24, Sotirios Mantziaris 
wrote:

> If i understand it correctly the proposed solutions does not solve the
> problem of forking repos.
> The ideal solution would be to have a import path agnostic of the repo
> location so that a fork could be up and downstream compatible.
>
> On Thursday, December 13, 2018 at 12:32:11 AM UTC+2, Ian Lance Taylor
> wrote:
>
>> On Wed, Dec 12, 2018 at 8:08 AM Robert Engels 
>> wrote:
>> >
>> > I am pretty sure that the correct solution is to decouple the package
>> from its location. And a global Go registry can tell Go get where that
>> package can currently be found.
>>
>> You don't need a global registry.  Or, rather, the global registry can
>> be DNS.  You can set up your own trivial redirector, using a meta tag,
>> as discussed at https://golang.org/cmd/go/#hdr-Remote_import_paths .
>> Or you can use an existing general purpose redirector such as
>> gopkg.in.  Either way you can enforce this with an import comment as
>> discussed at https://golang.org/cmd/go/#hdr-Import_path_checking .
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

Re: [go-nuts] Re: Go assembly interface calls

[Nathan Fisher]

One trick I’ve used when writing algorithms that use SSE is write it in Go
first, run go build to output the assembler for the function, and then
tweak the output manually.
On Sat, Dec 15, 2018 at 09:36, Jason E. Aten  wrote:

> reflect.Method(i) and reflect.MethodByName("myFunc") have got to be fully
> dynamic, perhaps they hold a clue.
>
> On Saturday, December 15, 2018 at 8:20:20 AM UTC-6, Robert Engels wrote:
>>
>> That’s a possibility, but I would think there must be some assembly
>> syntax to obtain the offset of a method of an interface function table.
>> When you look at the assembly generated the offsets are constants...
>>  otherwise you need to perform multiple lookups to determine it - ruining
>> the performance. If I hardcore the constant than any change to the
>> interface breaks the assembly code, but I guess that’s the same for struct
>> parameters and parameter order in general.
>>
>> On Dec 15, 2018, at 8:12 AM, Jason E. Aten  wrote:
>>
>> On Saturday, December 15, 2018 at 1:29:14 AM UTC-6, robert engels wrote:
>>>
>>> Are there any examples of a hand-written assembly function that accepts
>>> an interface and then makes calls on the interface methods?
>>>
>>> In reviewing the documentation, it seems impossible, as the PCDATA, and
>>> FUNCDATA are not documented, and thus, I think the GC scanner ends up
>>> barfing when these are omitted.
>>>
>>> Although, since the interface is passed as a parameter, I would expect
>>> that the caller would retain the reference, so adding NO_LOCAL_POINTERS
>>> should suffice, but it is failing.
>>>
>>> Any help would be appreciated. Thanks.
>>
>>
>> I would try writing what I wanted to do using the `reflect` package, and
>> then looking at the disassembly of it.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>>
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

Re: [go-nuts] Go offline development recommendations

[Nathan Fisher]

We use dep at work and commit the vendor folder. The main benefit we see is
that it ensures consistent builds across machines, tends to be faster, and
allows offline development. assuming you don’t have to use a third party
security or infrastructure team to download the dependencies. If you do
then it can be a bit of a nuisance because they need the tooling on their
machine. Committing the vendor folder is a lot less effort than alternative
solutions from my experience in similarly restrictive environments.
On Thu, Dec 13, 2018 at 09:00, akshita babel 
wrote:

> Hey, can anyone guide me on how to take octet stream as input in API
> and/or how to convert octet stream to byte array using golang
>
> On Thu, Dec 13, 2018 at 5:14 PM snmed  wrote:
>
>> I'm not sure if i fully understand your point on "vetted binaries", but
>> if every source code is vetted and then transferred to the isolated
>> environment, there should not be a problem with security issues. All the
>> developer machine living already in the same isolated environment and also
>> i would place athens there, so all builds will be made with vetted source
>> code.
>>
>> It's easily possible that i miss some import point in this scenario, but
>> anyway i will verify your idea and take it into account for our go
>> development strategy.
>>
>> Am Donnerstag, 13. Dezember 2018 10:38:30 UTC+1 schrieb ohir:
>>>
>>> On Wed, 12 Dec 2018 22:15:23 -0800 (PST)
>>> snmed  wrote:
>>>
>>> > Thank you very much for your reply. It seems to be a possible way to
>>> do it,
>>> > what do you think about the athens way?
>>>
>>> From the secop pov it'll be a hells gate. Also it does not allow for
>>> vetted binary arifacts as current unix/Go ways do.
>>>
>>> > what do you think about the athens way?
>>>
>>> 1) Athens is in flux. 2) It is yet another complicated piece of software
>>> to analyze and monitor. 3) It again brings all compiling to the local
>>> machine while GOPATH way allows all devs to use binary artifacts built
>>> on the hardened builder machine.
>>>
>>> > In my point of view it would be the easiest way as far i can preload
>>> the
>>> > athens cache with all the required packages.
>>>
>>> So the security team will need to produce an internal vetted package
>>> instead
>>> of signing a tag within the IDP 3rd party package repo.
>>>
>>> (IMO whole idea of "zipped packages" is the bad J-flu infection... Ah -
>>> CoC)
>>>
>>> > And then the only thing a developer has to do, is to set the GOPROXY
>>> to the
>>> > athens instance.
>>>
>>> It fits loose distributed settings. Not controlled ones. And I -- from
>>> "offline"/"airgap" constraint -- assumed that your client is concerned
>>> about
>>> security, not about connectivity.
>>>
>>> Hope this helps,
>>>
>>> --
>>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

Re: [go-nuts] Re: go language sensitive editor?

[Nathan Fisher]

Agree on this. Gorename and gofmt etc provide only a small subset of what
is on GoLands roadmap. I toggle between vs code, vim(-go), and GoLand.
There’s bits I like about all 3 but if I had to choose only one I’d
probably go with GoLand.

On Tue, Nov 20, 2018 at 20:24, robert engels  wrote:

> I used both VSCode and Intellij/GoLand. I suggest Intellij/GoLand for
> anything but trivial projects. The refactoring and navigation tools are far
> superior to those available in VS code, and it makes working in larger
> projects with lots of dependencies far easier IMO.
>
>
> On Nov 20, 2018, at 3:15 PM, buc...@gmail.com wrote:
>
>
> Another vote for VS Code. I'm a hobbyist and have tried lots of editors.
>
> On Tuesday, November 20, 2018 at 1:52:11 PM UTC-7, Pat Farrell wrote:
>>
>> I know, this is both a FAQ and an unanswerable question. I'm an old
>> programmer who has used nearly every editor known to man. I am not a fan of
>> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>>
>> What editors do folks use for go? I'd like something that can complete
>> function names, understand imports, and give some assistance.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

[go-nuts] Re: Go 1.11.2 and Go 1.10.5 are released

[Nathan Kerr]

I updated my release related resources:


   - Go Release Timeline 
   - When Should You Upgrade Go? 
   


On Friday, November 2, 2018 at 3:06:58 PM UTC-7, Andrew Bonventre wrote:
>
> Hello gophers,
>
> We have just released Go versions 1.11.2 and 1.10.5, minor point releases.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.11.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.11.2" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> Cheers,
> Andy for the Go Team
>

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

Re: [go-nuts] Heap of structs

[Nathan Fisher]

Is there a specific issue you’re experiencing in trying to implement it?

Suggestions/observations:

- export the struct (Str instead of str) if you’re exporting the Heap.
- same for the fields in the struct unless you have a constructor function
(eg New) and appropriate functions to modify/view them in the same package
scope.
- assuming you want it sorted by the fields you can implement the sort
interface[1] on either or both fields.

1 - https://godoc.org/sort#Interface
On Thu, Nov 1, 2018 at 15:57, Alex Dvoretskiy 
wrote:

> How can I rewrite this code to use a heap of structs instead of a heap of
> ints?
>
> Have:
> type IntHeap []int
>
> Need:
> type str struct {
> num int,
> val string
> }
>
> type Heap []str
>
>
> https://play.golang.org/p/KHhIvKMkNMy
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

Re: [go-nuts] Re: gomobile: what's the right way to make widgets?

[Nathan Verrilli]

Regarding cross-platform GUI:

The below author has it precisely correct. As, after decades of effort, 
Qt 'mostly works' suggests strongly that those who care about their UI 
will end up implementing UI natively, and separating it from their code. 
Those who don't care will be happy to use something that 'mostly works'.


Neither case suggests that a cross-platform GUI is a useful addition to 
Go (and my own conclusion is that they show such a platform is not).


Cheers,
Nathan

On 10/27/2018 7:34 AM, Gerald Henriksen wrote:


An acceptable cross-platform GUI is a major undertaking to create an
even half way acceptable outcome.

Far better to somehow interface with an existing solution like Qt
which has already spent the decades creating something that mostly
works.



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

Re: [go-nuts] Using a defer func() closure to call c.free

[Nathan Davies]

Ok, that's an interesting line of investigation - I'll take a look into
that and let you know if I find anything.

Thanks
Nathan

On Thu, 11 Oct 2018 at 13:04, Robert Engels  wrote:

> It is not necessarily the open doc that is freeing the memory, could be
> the close doc as well - meaning it needs the file and opt reference while
> it is open. Probably not file, but possible opt. The other thing are you
> sure that the opt doesn’t contain a reference that is freed to early...
>
> On Oct 11, 2018, at 6:57 AM, ndav...@turnitin.com wrote:
>
> Hi,
>
> That was at least a working theory there for a while; that perhaps the
> open document was doing some freeing of the memory before it returned. The
> reason we discounted that was some docs the defer func() free works fine.
> It could be a weird bug in that library, and I'm still considering that
> option :) What moved us away from that is that when we had the defer func()
> approach a certain set of docs failed every time with this issue. Move to
> the code we have now and all those docs work as expected.
>
> It's a really odd one. I'm ok with the code as it is now. I just would
> like to understand some more. Thanks for taking a look and for asking
> questions. Please keep doing so, you never know we may get to the bottom of
> this.
>
> Thanks
> Nathan
>
>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
Nathan Davies
Senior Software Engineer

Turnitin
36 Gallowgate, Wellbar Central, Newcastle upon Tyne, NE1 4TD, UK
Direct: +44 (0) 191 681-0334 <0191%20681%200235> (internally Ext: 2344)
Office: +44 (0) 191 681-0200
Email: ndav...@turnitin.com
Web: www.turnitin.com

Turnitin is a Registered product of Turnitin UK, Ltd which is a wholly
owned subsidiary of Turnitin, LLC. Turnitin UK, Ltd is a company registered
in England and Wales with company number   07321841.



DISCLAIMER: This e-mail and any files transmitted with it are confidential
and intended solely for use by the recipient to which it is addressed. If
this email has been misdirected in error please contact us on+44 (0)
191 681 0200. This e-mail and any attachments have been scanned for viruses
prior to sending. No liability will be accepted for any loss incurred as a
result of any viruses being passed on. Any form of unauthorised publication
or distribution is strictly prohibited.

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

[go-nuts] [ANN] Get Programming with Go is now available in print

[Nathan Youngman]

Get Programming with Go is a beginner's guide to the Go programming 
language containing 32 quick lessons with plenty of fun exercises and silly 
gopher illustrations.

It's now available in print, and my publisher has made it the deal of the 
day today (September 19th, 2018). Half off the ebook and print versions, 
with international shipping available.

Deal of the Day: https://yng.mn/dotd

--
Nathan Youngman
https://programminggo.com/

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

Re: [go-nuts] go1.11 no longer supports compressed hostnames in SRV lookup replies

[Nathan Fisher]

Can you share examples?
On Wed, Aug 29, 2018 at 19:08,  wrote:

> We are using SRV records in Kubernetes for various purposes and Go 1.11 no
> longer supports compressed names in SRV resource data (
> https://github.com/golang/net/commit/24dd3780ca4f75fed9f321890729414a4b5d3f13#diff-47e2241916c7047eab73daf76c89fc3fR2055).
> The error we are getting is "cannot unmarshal DNS message" and the
> underlying error is "Target: compressed name in SRV resource data".
>
> Ultimately, we believe the issue lies with dnsmasq returning a
> non-compliant SRV response, but it is stopping us from upgrading to Go1.11.
> Are there any known workarounds which would allow us to handle these
> noncompliant SRV responses?
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

[go-nuts] Re: Go 1.11 and 1.10.4 are Released

[Nathan Kerr]

I updated my release related resources:

   - Go Release Timeline 
   - When Should You Upgrade Go? 
   
   

On Friday, August 24, 2018 at 3:24:25 PM UTC-7, Andrew Bonventre wrote:
>
> Hello gophers,
>
> We just released Go 1.11 and 1.10.4.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.1 1
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.11" or "git checkout go1.10.4" and build as usual.
>
> To find out what has changed in Go 1.11, read the release notes:
>   https://golang.org/doc/go1.1 1
>
> Thanks to everyone who contributed to the release!
>
> Cheers,
> The Go Team
>

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

Re: [go-nuts] Ternary ... again

[Nathan Youngman]

Mark,

Funny that -- you suggest that adding another syntax for the same behaviour 
"might help with adoption".

I think the opposite is true. 

My friend has been learning iOS development and has found many things 
confusing. There is the lambda syntax in Swift, and then the trailing 
lambda syntax (Scala does a similar thing, much like Ruby blocks). There is 
the already peculiar method signature that includes parameter names (a 
hold-over from Objective-C), but then there are exceptions to the rule as 
you go deeper. So many variations to keep straight and so many things to 
learn all at once.

What is the real benefit of this complexity?

No. I think Go's simplicity is what will help with adoption -- especially 
as brand new developers come online.

Software development isn't writing poetry. The goal isn't words that look 
nice on a page and cause you to ponder what the author was feeling. Maybe 
the verbosity of Go isn't as "enjoyable" to read as your favourite 
language, but it is easy to understand.

Nathan.

https://yng.mn/programminggo


On Wednesday, 15 August 2018 05:23:36 UTC-6, Mark Volkmann wrote:
>
> I realize I’m just another new person to Go asking for features that have 
> been discussed many times before and that are very unlikely to be changed. 
> But I’d like to consider a kind of middle ground that applies to many 
> potential features.
>
> I understand that many requests for syntax additions are rejected on two 
> grounds. One is that it is possible to abuse the feature, resulting in code 
> that is more difficult to understand. Another is that it makes the language 
> specification larger, adding to the list of things that new Go developers 
> must learn.
>
> I see many proposals that would reduce the amount of code to be typed 
> rejected on the basis that doing that alone is not a valid reason to add a 
> feature. For things that would not be used often, I agree with that. But I 
> want to discuss two features that I use often in other languages.
>
> The first is ternaries. What if only simple, non-nested ternaries were 
> supported? For example, color := temperature > 100 ? “red” : “blue”. This 
> seems so much more clear than the map[bool]:string trick that some have 
> proposed. Writing this with an if statement takes either 4 or 6 lines. This 
> comes up often enough in code to make a significant difference. I think 
> it’s hard to argue that this has the potential to make code harder to read 
> if they can’t be nested.
>
> The second is arrow functions. What if only functions that return the 
> result of a single expression were supported? For example, n => n * 2. 
> Compare this to func (n int) { return n * 2 }. The value of this is closely 
> tied to whether generics are added to the language at some point.
>
> Adding just a few things like these to the language might help with 
> adoption and that in itself is a worthwhile goal. I suspect many developers 
> that love Go aren’t currently using it on real projects. Getting more 
> developers to consider Go makes that more likely.
>
> ---
> R. Mark Volkmann
> Object Computing, Inc.
>
> On Aug 14, 2018, at 12:18 PM, Axel Wagner  > wrote:
>
> There is lots of discussion findable here:
> https://groups.google.com/forum/#!searchin/golang-nuts/ternary%7Csort:date
> There's a bit of discussion on the issue tracker:
> https://github.com/golang/go/issues?utf8=%E2%9C%93&q=ternary+operator -- 
> in particular https://github.com/golang/go/issues/23248
> There's more discussion on the reddit:
>
> https://www.reddit.com/r/golang/comments/5dqpab/what_is_the_reasoning_behind_go_not_having_a/
>
>
> On Tue, Aug 14, 2018 at 6:43 PM Mark Volkmann  > wrote:
>
>> I’m new to Go and I imagine the idea of adding a ternary operator to Go 
>> has been discussed many times. Rather than repeat that, can someone point 
>> me to a discussion about why Go doesn’t add this? I’m struggling to 
>> understand why it is desirable to write code like this:
>>
>> var color
>> if temperature > 100 {
>> color = “red”
>> } else {
>> color = “blue”
>> }
>>
>> Instead of this:
>>
>> var color = temperature > 100 ? “red” : “blue”
>>
>> Is the ternary really so confusing that it justifies writing 6 lines of 
>> code instead of 1? I realize I could eliminate two lines like the 
>> following, but this isn’t a good idea if the values come from function 
>> calls since there would sometimes be needless function calls.
>>
>> var color = “blue”
>> if temperature > 100 {
>> color = “red”
>> }
>>
>> ---
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>>

[go-nuts] Re: Go 1.10.2 and Go 1.9.5 are released

[Nathan Kerr]

I updated my release related resources:

   - Go Release Timeline <https://pocketgophers.com/go-release-timeline/>
   - When Should You Upgrade Go? 
   <https://pocketgophers.com/when-should-you-upgrade-go/>
   
Nathan

On Tuesday, May 1, 2018 at 10:04:38 AM UTC-7, Andrew Bonventre wrote:
>
> Hi gophers,
>
> We have just released Go versions 1.10.2 and 1.9.6, minor point releases.
>
> These releases include fixes to the compiler, linker, and go command.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.10.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.10.2" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> The Go Team
>
>

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

Re: [go-nuts] Re: Measure Memory Fragmentation

[Nathan Fisher]

Do you mean wrt to Go or more generally? I could see using a histogram with
a logarithmic bucket size or similar. Where the bucket sizes are the
maximum length in bytes a given “open slot” can hold and the count is the
number of occurrences of that size in the pool.

On Sat, Apr 28, 2018 at 6:18 PM, Kaveh Shahbazian <
kaveh.shahbaz...@gmail.com> wrote:

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

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

[go-nuts] Re: Go 1.10.1 and Go 1.9.5 are released

[Nathan Kerr]

I've updated my release related resources:

   - Go Release Timeline <https://pocketgophers.com/go-release-timeline/>
   - When Should You Upgrade Go? 
   <https://pocketgophers.com/when-should-you-upgrade-go/>
   
Nathan

On Thursday, March 29, 2018 at 8:17:34 AM UTC-7, Andrew Bonventre wrote:
>
> Hi gophers,
>
> We have just released Go versions 1.10.1 and 1.9.5, minor point releases.
>
> These releases include fixes to the compiler, runtime, go command, and the
> archive/zip, crypto/tls, crypto/x509, encoding/json, net, net/http, and
> net/http/pprof packages.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.10.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.10.1" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> The Go Team
>

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

Re: [go-nuts] Flutter and golang

[Nathan Fisher]

Oh that’s awesome! I didn’t realise they were supporting desktop now. It
sounded like it was abandoned in a push to focus on the mobile experience.
On Sat, Mar 10, 2018 at 4:36 PM, Ged Wed  wrote:

> I used QT for 6 months and Flutter is way ahead.
> QT has a huge licensing issue. You can only use QT and not pay a yearly
> fee of 3 k if you provide the ability for end users to recompile your app
> against QT.
> Also it's got a lot of rough edges once you get into the 80/20 situation
> on real world apps.
> It takes 20% of your time to get 80% of your app done, and 80% of your
> time to get the last 20% of your app done.
> Flutters plug-in system avoids you getting cornered in the 80/20 situation.
>
> I started to do an integration of botldb and some other golang code but am
> half way through. From what I can see there are no roadblocks. There is one
> issue with APK packing but I think it just need a script to fix it.
> I have not published on GitHub yet because it's not done but will..gedw99
> is my GitHub org
>
> There is a repo there called CI where I am also getting continuous build
> going for flutter with golang for iOS and Android.
> I intend to extend it for all Desktops too.
>
> https://github.com/gedw99/ci
>
>
> On Sat, Mar 10, 2018, 10:16 PM Justin Israel 
> wrote:
>
>>
>>
>> On Sun, Mar 11, 2018, 9:28 AM Ged Wed  wrote:
>>
>>> I am starting to develop an app using flutter and golang.
>>>
>>> Flutter is the dumb GUI and everything else is written in golang.
>>>
>>> It is reasonably easy to compile your golang code using gomobile and
>>> then bind to flutter using the Method Channel API that flutter provides.
>>>
>>> Is anyone interested in this ?
>>>
>>
>> I was just recently considering getting some mobile dev practice in, and
>> was thinking whether to use a flutter approach or something with Qt and
>> gomobile. I would be very interested in reading a write up of your
>> experience getting started with Flutter + gomobile
>>
>>
>>> Flutter now runs on all desktops and mobiles officially. The desktop
>>> version was announced 2 weeks ago and already Linux and macOS works, with
>>> Windows probably being a few weeks away from what I guesstimate.
>>>
>>> The cool thing about this is that you get a very well supported and high
>>> performance GUI engine for Forms and 2D. 3D is still not provided by has
>>> been stated by the team to be looked at later.
>>>
>>> Anyway I hope to spark some interest in this and I will be putting up
>>> some demo code on my git hub repo and hope others are interested enough to
>>> also give it a try and work through it.
>>>
>>>
>>> How to write a plug-in:
>>>
>>> https://flutter.io/platform-channels/
>>>
>>> Plugins already available :
>>>
>>> https://pub.dartlang.org/flutter/packages
>>>
>>> Printing.
>>> They have not yet officially committed to how cross platform out put to
>>> PDF and XPS ( for windows ) will be supported.
>>> Under the covers Flutter is using the same engine that Google Chrome
>>> browser uses; called Skia.
>>>
>>> Skia has an API for printing web pages and it uses pdfium under the hood.
>>> It seams logical that the Flutter team will also start using this method
>>> to provide built in PDF output and even print spooling but from what I can
>>> see it's not resolved yet.
>>>
>>> All other things like touch, keyboard, sound, gestures etc are all built
>>> into Flutter because it's built into Skia.
>>>
>>> Would be great to hear if there is a strong interest in this and to
>>> discuss .
>>
>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

Re: [go-nuts] Re: [ANN] Get Programming with Go

[Nathan Youngman]

Yup. The "about this book" section in the front matter does suggest that
seasoned C/C++ programmers look elsewhere, though perhaps it could be
written more directly, or maybe in more places? Here's a quote from the
front matter:

"If you are a polyglot programmer who understands the merits of static
typing and composition over inheritance, if pointers and mutexes are second
nature, if optimizing memory allocations and CPU caches are an old hat, you
will find plenty of books and resources that ramp up quickly and cover
advanced topics more thoroughly."

Have you looked at http://www.gopl.io/ ?

Nathan.


On 8 March 2018 at 12:41,  wrote:

>
> On Wednesday, 7 March 2018 10:46:58 UTC-4, Nathan Youngman wrote:
>>
>> Learn about error handling and concurrent state in the latest release of
>> Get Programming with Go, available from Manning Books.
>>
>> The first draft is complete. If you have any feedback, now’s the time to
>> get it in, as we are currently editing the book before it goes to
>> production.
>>
>> https://bit.ly/programminggo
>>
>>
>> I'd recommend specifying your target audience.  That would appear to
> exclude seasoned C/C++ programmers.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/_-35shjZqUU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Nathan Youngman
Email: he...@nathany.com
Web: https://nathany.com

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

Re: [go-nuts] Re: [ANN] Get Programming with Go

[Nathan Youngman]

Hi Matthew,

First of all, thanks for looking at the free chapters and providing
feedback.

I think I should reword the paragraph about the data centre, because there
is what Go was initially announced as, and then there is the niche that it
now occupies -- the later being predominately network services that tend to
run in data centres (65% according to
https://blog.golang.org/survey2017-results).

I'm not sure if "in English" really describes Go. Languages like Ruby
purport to offer English-like syntax (see "Beautiful Code: Leading
Programmers Explain How They Think") through metaprogramming tricks. On the
other hand, Go strives for simplicity and, in my opinion, clarity -- even
at the cost of verbosity in some cases. Whereas Ruby "reads like an essay",
code written in Go "does what it says."

The book layout isn't final, as it's still in early access. I think it will
look much nicer after it goes through the production phase -- finger's
crossed. A fair amount of that is outside of my control as the author. Even
the book cover is out of my hands, though I can and have given the
publisher feedback.

As far as competition, the only book that comes to mind as
beginner-oriented is Caleb Doxsey's "Introducing Go" published through
O'Reilly. There may be others that I'm not aware of.
http://shop.oreilly.com/product/0636920046516.do I'm not sure if either
Caleb's book or ours is suitable for the absolute beginner. Learning
something like Scratch may be advisable first, to get the concepts down.

Nathan.

P.S. If you decide to buy a copy or recommend it to others, the discount
code *39youngman* will give 39% off either the paper book or ebook. Also,
my affiliate link earns me a few bucks: https://bit.ly/programminggo


On 7 March 2018 at 09:02,  wrote:

> Go is designed for the modern data center, but its adoption isn’t
>> restricted to the workplace.
>
>
> While the garbage collector may point to this, and I’ve previously argued
> about data centers stepping on other applications’ feet, my understanding
> is the stated goal is systems programming. This term encompasses anything
> designed as part of a larger system in my mind; OS drivers and components
> have been mentioned, the compiler is written in Go, build and other scripts
> are easy to write in Go, OS CLI tools are great in Go, you’ve mentioned
> embedded programming, small web servers with database definitely work, and
> of course data center applications and infrastructure are a major Go target
> and consumer.
>
> Perhaps something like “Go is designed for programming modern computers
> and computer systems in English” would be more accurate?
>
> I’ve only looked at the three free chapters, but one thing that stands out
> to me is the amount of formatting on each page. Although I’m looking on a
> computer and not at a book, it seems that all of the italics, bolds,
> blocks, lines, references, pictures, and other formatting add noise. I do
> think the graphics are creative, slicing the solar system is great.
>
> It’s been asked here about references for new programmers but I didn’t
> have an answer besides “what do you want to know?”. Can you share your
> competition here? I’ll mention “Get Programming with Go” in the future.
>
> Thanks,
> Matt
>
> On Wednesday, March 7, 2018 at 8:46:58 AM UTC-6, Nathan Youngman wrote:
>>
>> Learn about error handling and concurrent state in the latest release of
>> Get Programming with Go, available from Manning Books.
>>
>> The first draft is complete. If you have any feedback, now’s the time to
>> get it in, as we are currently editing the book before it goes to
>> production.
>>
>> https://bit.ly/programminggo
>>
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/_-35shjZqUU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Nathan Youngman
Email: he...@nathany.com
Web: https://nathany.com

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

[go-nuts] [ANN] Get Programming with Go

[Nathan Youngman]

Learn about error handling and concurrent state in the latest release of 
Get Programming with Go, available from Manning Books.

The first draft is complete. If you have any feedback, now’s the time to 
get it in, as we are currently editing the book before it goes to 
production.

https://bit.ly/programminggo


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

[go-nuts] Re: How to merge labels along with json responses

[Nathan Kerr]

The general pattern for this is:

1. Create a data structure that reflects the JSON you want.
2. Fill it with data
3. Marshal or Encode

Since you have an example of the JSON you want, putting it through one of 
the tools from Generating Go structs from JSON 
 gives you something like:

type AutoGenerated struct { Status bool `json:"status"` Value struct { 
Types []string `json:"types"` Formula []string `json:"formula"` } 
`json:"value"` }

Now, instead of encoding when iterating though database rows, add the data 
to an instance of that data structure.

After it is filled up, Marshal or Encode the filled data structure to 
produce the JSON you desire.

On Monday, February 26, 2018 at 11:04:29 AM UTC-7, prince antony wrote:
>
>
> can anyone help me to merge labels along with the JSON responses I have my 
> code: https://play.golang.org/p/DB0S4byIHnc  and response: 
> https://play.golang.org/p/y7OOYB1h5z_C but I don't know to print JSON 
> responses like the below one  (expected output ): 
> https://play.golang.org/p/ejOJeTRqRTM How to print  the expected output
>

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

Re: [go-nuts] Re: Go 1.10 is released

[Nathan Kerr]

I have also updated my release related resources:


   - Go Release Timeline 
   - When Should You Upgrade Go? 
   
   
Enjoy!

On Monday, February 19, 2018 at 6:17:18 AM UTC-7, Michel Casabianca wrote:
>
> Hi Gophers,
>
> I have updated my list of Go interfaces for this release : 
> http://sweetohm.net/article/go-interfaces.en.html
>
> Enjoy!
>
> 2018-02-19 8:00 GMT+01:00 Henrik Johansson  >:
>
>> Thx,
>>
>> Why I wondered was because to build script (a tiny settings file really) 
>> for Archlinux uses this flag to build it's Go packages.
>> Is it available as a paranoia "i really need all the tests run"? Will it 
>> be removed later on?
>>
>>
>>
>>
>> sön 18 feb. 2018 kl 23:04 skrev Ian Lance Taylor > >:
>>
>>> On Sun, Feb 18, 2018 at 11:22 AM, Henrik Johansson >> > wrote:
>>> > The GOCACHE variable. What is it's effect when building Go itself?
>>> > It doesn't disable test caching when using the resulting go tools 
>>> right?
>>>
>>> Right.
>>>
>>> Ian
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Michel Casabianca
>

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

Re: [go-nuts] Re: Proposal: return if any not nil

[Nathan Fisher]

I think for me the benefit of a new statement is that it doesn't result in
changes to existing formatting/behaviour. Rather it provides a familiar
syntax and style semantic and results in no change to an existing code base
(e.g. it's opt in).

The problems I see with allowing 1 liner conditionals are;

- it breaks the existing reader flow for exception cases (this proposal
does as well but in a narrower scope).
- it results in ambiguity around how gofmt should behave.
- it would result in arbitrary churn relating to reformatting for existing
code bases or worse lilliputian arguments over code formatting if flags
were used.

I like the relatively consistent and unambiguous output that gofmt is able
to achieve.

If this new statement were used exclusively for error handling I could see
it testing for nil in the position of an error interface argument. Which
would essentially make it a macro that expands to the existing conditional
formatting with the same overhead as the multi-line conditional return
where;

func () (*Foo, error) {
  ...
  retnnerr nil, err

would effectively expand to the same representation as;

... // retnnerr nil, err was here
if err != nil {
  return nil, err
}

An alternative format could be to only specify the err variable as part of
the statement and then automatically apply the "default" value for all
other return params...

retnz err

I'm not sure I like that though because I think it is against Go's tendency
of being explicit in returns.

An issue I could see to both of the above is where multiple errors are
specified as a return value. I haven't seen that done in practise but
there's nothing in the language spec that prevents someone from writing an
API with that specification.

One way I could see addressing that with `retnnerr` is where constants and
blank/nil values are defined they would not be tested.

On Sat, 17 Feb 2018 at 09:14 Michael Jones  wrote:

> The notion of "return X if Y" is fun...it means I'm waking up to SNOBOL in
> 2018. Fantastic flashback but awkward here.
>
> Changing formatting to allow single line "if X { trivial Y }" seems
> natural.
>
> On Sat, Feb 17, 2018 at 6:05 AM,  wrote:
>
>> The OP's idea is the best one so far. What about the following.
>>
>> r, err := os.Open("blah.txt")
>> *return* nil *if* r == nil, err *if* err != nil
>>
>> basically every return field could be followed by an optional if clause
>> with an expression that must evaluate to bool.
>>
>> The return only happens if all optional if clauses evaluate to true.
>>
>> Could be also used to bubble errors up the stack
>>
>> r, err := os.Open("blah.txt")
>> *return* nil, fmt.Errorf("File open failed") *if* err != nil
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- sent from my mobile

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

[go-nuts] Proposal: return if any not nil

[Nathan Fisher]

Hi All,

I've been contemplating alternative methods to address the "boiler plate" 
of error handling in Go. One of the main benefits I see to the current 
approach is that indentation highlights exception paths vs the success 
path. From a readability perspective I can see the benefit of this 
approach. It allows a reader to efficiently scan a function.

One problem I see with the approach however is that it results in a lot of 
vertical expansion in the code. If you take a fail-fast and return such as 
the following it requires 4 lines of code for every check or worse people 
ignore the error with an underscore.

r, err := os.Open("blah.txt")
if err != nil {
return nil, err
}

What I've been thinking about is a return statement that will return only 
if all of the values are non-nil/blank.

The statement would enable you to replace the above with a single return as 
follows;

r, err := os.Open("blah.text")
retnn nil, err

I'm not wedded to the statement name retnn but more the general principle.

Thoughts?

Nathan

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

[go-nuts] Re: [security] Go 1.8.7, Go 1.9.4, and Go 1.10rc2 are released

[Nathan Kerr]

I updated my release related resources with these releases:

   - When Should You Upgrade Go? 
   <https://pocketgophers.com/when-should-you-upgrade-go/>
   - Go Release Timeline <https://pocketgophers.com/go-release-timeline/>
   
Nathan

On Wednesday, February 7, 2018 at 1:15:13 PM UTC-7, Andrew Bonventre wrote:
>
> Hi gophers,
>
> We have just released Go 1.8.7, Go 1.9.4, and Go 1.10rc2, to address a 
> recently-reported security issue. We recommend that all users update to one 
> of these releases (if you’re not sure which, choose Go 1.9.4).
>
> By using the clang or gcc plugin mechanism, it was possible for an 
> attacker to trick the “go get” command into executing arbitrary code. The 
> go command now restricts the set of allowed host compiler and linker 
> arguments in cgo source files to a list of allowed flags, in particular 
> disallowing -fplugin= and -plugin=. 
>
> The issue is CVE-2018-6574 and Go issue golang.org/issue/23672. See the 
> Go issue for details.
>
> Thanks to Christopher Brown of Mattermost for reporting this problem.
>
> Downloads are available at https://golang.org/dl for all supported 
> platforms.
>
> Cheers,
> Andy (on behalf of the Go team)
>
>

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

[go-nuts] net/http 404 error handling

[Nathan Fisher]

Hi All,

I came across this issue on GitHub relating to 404 handling in which Brad
F. said net/http will not implement templating.

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

Perhaps a silly question but why not change http.NotFound into a function
pointer like this:

```
var NotFound = func(w ResponseWriter, r *Request) {
  Error(w, "404 page not found", StatusNotFound)
}
```
This would allow it to be replaced on app start-up via init(), main(), etc.

It seems a quicker and cleaner solution to the boiler plate required for a
custom response writer and would maintain backwards compatibility.

The main drawback I see to it would be a nil pointer check (in which case
it could default to old behaviour).

Thoughts?

Kind regards,
Nathan
-- 
- sent from my mobile

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

[go-nuts] Re: Decode as JSON and store the JSON as blob in DB

[Nathan Kerr]

I think what was meant was to define Service as:

type Service struct {
ID   string `json:"id,omitempty" db:"id"`
Name string `json:"name" db:"name"`
Contract json.RawMessage `json:"contract" db:"contract"`
}

This assumes you don't need to access the contents of Service.Contract and 
they are meant to be stored in the db as a JSON-encoded blob (and that the 
db driver recognises json.RawMessage as something to store in a blob).

If one or more of these assumptions is not true, you will need separate 
structs for dealing with JSON and the db. For example:

type ServiceJSON struct {
ID   string `json:"id,omitempty"`
Name string `json:"name"`
Contract struct {
Ha  string `json:"ha"`
ServiceTime int`json:"service_time"`
Region  string `json:"region"`
} `json:"contract"`
}

and

type ServiceDB struct {
ID   string `db:"id"`
Name string `db:"name"`
Contract []byte `db:"contract"`
}

and convert between them as needed.

Hope this helps,
Nathan

On Friday, November 17, 2017 at 8:31:19 AM UTC+1, mail...@gmail.com wrote:
>
> Tamas,
>
> Can u explain ?
>
> On Thursday, November 16, 2017 at 11:47:03 PM UTC+5:30, Tamás Gulácsi 
> wrote:
>>
>> json.RawMessage
>
>

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

[go-nuts] [ANN] Pocket Gophers’ Guide to JSON - Early Access Special

[Nathan Kerr]

The Pocket Gophers’ Guide to JSON 

Learn how to confidently handle *any* JSON with the Pocket Gophers’ Guide 
to JSON.

You’ll learn a universal approach to deal with any JSON that leverages 
encoding/json and other JSON tools in the Go ecosystem along with how to 
evaluate your implementation.

The Pocket Gophers’ Guide to JSON includes a PDF that explains the 
approach, the tools, and the evaluation method. The guide also includes 
examples based on real-world JSON with many solutions (where possible) with 
detailed evaluations.

You’ll learn how to efficiently handle your JSON with confidence that your 
solution balances the implementation with how dynamic the JSON is and at 
the same time be idiomatic Go.

Just fire up your editor and buy The Pocket Gophers’ Guide to JSON. Then 
you’ll be confidently handling *any* JSON today.

Early Access Special


   - 40% off the full price of $50!
   - Free updates as they are released!
   - The price will go up as the guide reaches completion.


Learn more about the Guide 

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

Re: [go-nuts] Memory leak when calling highly parallel goroutines

[Nathan Kerr]

Read Ways to limit concurrent resource use 
 for different methods 
that can be used to limit concurrency along with example code.

On Wednesday, October 25, 2017 at 9:05:44 PM UTC+2, Tamás Gulácsi wrote:
>
> Just blind shots:
> resp.Body.Close(),
> sync.Pool the buffers,
> Limit concurrency - the simplest is a make(chan struct{}, 512) ans 
> push/pull empry tokens to it.

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

[go-nuts] Re: Go 1.9.2 and Go 1.8.5 are released

[Nathan Kerr]

I updated my release related resources:

   - Go Release Timeline <https://pocketgophers.com/go-release-timeline/>
   - When Should You Upgrade Go? 
   <https://pocketgophers.com/when-should-you-upgrade-go/>
   
Nathan

On Thursday, October 26, 2017 at 1:52:13 AM UTC+2, Chris Broadfoot wrote:
>
> Hi gophers,
>
> We have just released Go versions 1.9.2 and 1.8.5, minor point releases.
>
> These releases include fixes to the compiler, linker, runtime, 
> documentation, go command, and the crypto/x509, database/sql, log, and 
> net/smtp packages. They include a fix to a bug introduced in Go 1.9.1 and 
> Go 1.8.4 that broke "go get" of non-Git repositories under certain 
> conditions.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.9.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with "git 
> checkout go1.9.2" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> Chris
>

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

Re: [go-nuts] repeatable builds

[Nathan Kerr]

Another option for 2 is https://github.com/cloudflare/hellogopher

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

[go-nuts] Re: [security] Go 1.8.4 and Go 1.9.1 are released

[Nathan Kerr]

I updated my release related resources:

   - Go Release Timeline <https://pocketgophers.com/go-release-timeline/>
   - When Should You Upgrade Go? 
   <https://pocketgophers.com/when-should-you-upgrade-go/>
   
Hope the community finds them useful.

Nathan


On Wednesday, October 4, 2017 at 10:35:07 PM UTC+2, Chris Broadfoot wrote:
>
> Hi gophers,
>
> Two security-related issues were recently reported.
> To address this issue, we have just released Go 1.8.4 and Go 1.9.1.
>
> We recommend that all users update to one of these releases (if you're not 
> sure which, choose Go 1.9.1).
>
> The issues addressed by these releases are:
>
> By nesting a git checkout inside another version control repository, it 
> was possible for an attacker to trick the “go get” command into executing 
> arbitrary code. The go command now refuses to use version control checkouts 
> found inside other version control systems, with an exception for git 
> submodules (git inside git).
> The issue is tracked as https://golang.org/issue/22125 (Go 1.8.4) and 
> https://golang.org/issue/22131 (Go 1.9.1). Fixes are linked from the 
> issues.
> Thanks to Simon Rawet for the report.
>
> In the smtp package, PlainAuth is documented as sending credentials only 
> over authenticated, encrypted TLS connections, but it was changed in Go 1.1 
> to also send credentials on non-TLS connections when the remote server 
> advertises that PLAIN authentication is supported. The change was meant to 
> allow use of PLAIN authentication on localhost, but it has the effect of 
> allowing a man-in-the-middle attacker to harvest credentials. PlainAuth now 
> requires either TLS or a localhost connection before sending credentials, 
> regardless of what the remote server claims.
> This issue is tracked as https://golang.org/issue/22134 (Go 1.8.4) and 
> https://golang.org/issue/22133 (Go 1.9.1). Fixes are linked from the 
> issues.
> Thanks to Stevie Johnstone for the report.
>
> Downloads are available at https://golang.org/dl for all supported 
> platforms.
>
> Cheers,
> Chris (on behalf of the Go team)
>
>

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

[go-nuts] Re: Go 1.9 is released

[Nathan Kerr]

Congrats!

I updated my Go Release Timeline 
 and When Should You 
Upgrade Go?  pages.

On Friday, August 25, 2017 at 12:44:25 AM UTC+2, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We just released Go 1.9.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.9
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.9" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.9
>
> Thanks to everyone who contributed to the release.
>
> Chris
>

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

[go-nuts] Re: Go eval the source

[Nathan Kerr]

I wrote an expanded explanation for the second option: Exploring 
alternatives with go run 
<https://pocketgophers.com/exploring-alternatives-with-go-run/>.

On Saturday, July 22, 2017 at 4:13:27 PM UTC+2, Tong Sun wrote:
>
> Fabulous! Thanks Nathan!
>
> On Saturday, July 22, 2017 at 1:41:12 AM UTC-4, Nathan Kerr wrote:
>>
>> A couple other options:
>>
>> 1. modify your code, compile, run
>> 2. put most of your code in main.go, each specific sort method in a 
>> separate file (e.g., specific.go) so that go run main.go specific.go will 
>> use the sorting you need. See https://pocketgophers.com/10-to-instrument/ 
>> for an example of this setup.
>>
>> On Friday, July 21, 2017 at 9:31:26 PM UTC+2, Tong Sun wrote:
>>>
>>> Hi, 
>>>
>>> I've done some searching before posting, so I know there are a few 
>>> packages out there that can do go eval, but am wondering which one best 
>>> suits the following purpose --
>>>
>>> I want to sort JSON array using Go, because each case would be different 
>>> for the different JSON arrays that I'm sorting, and this is only for myself 
>>> (to get the job done), so I want to do it as simple as possible. Thus 
>>> defining the sort comparing functions on the fly for the very JSON I'm 
>>> sorting at the moment seems to be the easiest route. 
>>>
>>> Is it so? Any better way to do it?
>>> Is https://github.com/sbinet/go-eval still the best package for doing 
>>> go eval like above?
>>>
>>> Thanks
>>>
>>>
>>>

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

[go-nuts] What is pprof overhead like when gathering a profile?

[nathan]

Hello,

I am curious what the performance impact of running pprof to collect 
information about CPU or memory usage is. Is it like strace where there 
could be a massive slowdown (up to 100x) or is it lower overhead, i.e., 
safe to use in production? The article here 
- 
http://artem.krylysov.com/blog/2017/03/13/profiling-and-optimizing-go-web-applications/
 
- suggests that "one of the biggest pprof advantages is that it has low 
overhead and can be used in a production environment on a live traffic 
without any noticeable performance penalties". Is that accurate?

Thanks!

Nathan

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

[go-nuts] Re: How to determine when to actually use goroutines?

[nathan]

> I need to query a db to get its content type and then send the actually 
file that lives on the file system. Now the question is, should I put 
db.QueryRow and os.Open each in a goroutine to make them concurrent?

Why make them concurrent if you need to know to know the end result of the 
DB call *before* opening the file?

> Should I writing things sequentially by default and only when hitting 
performance problems do I profile the program and wrap calls in goroutine?

Personally I would say yes, only use goroutines when you know for a fact 
that you have an issue which needs solving via concurrency, e.g., IO-bound 
workloads. While it's nice to have goroutines and channels within easy 
reach, they do complicate program structure and can cause data races if not 
used properly. Unless your app is problematically slow, design everything 
to be as simple as possible. People tend to assume things like "DB queries 
are slow" or "filesystem access is slow", but that doesn't mean doing 
either of those things will cause issues, and even if they do, solutions 
such as adding indexes to problematic fields or doing caching might help A 
LOT more than trying to be more concurrent will.


On Monday, July 24, 2017 at 8:34:30 AM UTC-7, Glen Huang wrote:
>
> Hi,
>
> I'm still pretty new to go. Hope this question isn't too stupid.
>
> I'm writing a restful API server, and in order to send a response, I need 
> to query a db to get its content type and then send the actually file that 
> lives on the file system. Now the question is, should I put db.QueryRow and 
> os.Open each in a goroutine to make them concurrent?
>
> And a more general question is, when using APIs from the stdlib or 
> 3rd-party packages, how do I determine whether to wrap them in goroutines 
> when more than one of them need to happen sequentially and the order 
> actually doesn't matter? Should I manually time the API executions to make 
> the call? Should I writing things sequentially by default and only when 
> hitting performance problems do I profile the program and wrap calls in 
> goroutine?
>
> How do you decide when to use goroutines?
>

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

[go-nuts] Re: Go eval the source

[Nathan Kerr]

A couple other options:

1. modify your code, compile, run
2. put most of your code in main.go, each specific sort method in a 
separate file (e.g., specific.go) so that go run main.go specific.go will 
use the sorting you need. See https://pocketgophers.com/10-to-instrument/ 
for an example of this setup.

On Friday, July 21, 2017 at 9:31:26 PM UTC+2, Tong Sun wrote:
>
> Hi, 
>
> I've done some searching before posting, so I know there are a few 
> packages out there that can do go eval, but am wondering which one best 
> suits the following purpose --
>
> I want to sort JSON array using Go, because each case would be different 
> for the different JSON arrays that I'm sorting, and this is only for myself 
> (to get the job done), so I want to do it as simple as possible. Thus 
> defining the sort comparing functions on the fly for the very JSON I'm 
> sorting at the moment seems to be the easiest route. 
>
> Is it so? Any better way to do it?
> Is https://github.com/sbinet/go-eval still the best package for doing go 
> eval like above?
>
> Thanks
>
>
>

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

Re: [go-nuts] Will cmd/compile/internal/gc be replaced in the future?

[Nathan Kerr]

The ones in the compiler were initially implemented in C. They were 
converted to Go for go1.5.

The others were created to build tools in Go like gofmt.

On Wednesday, July 19, 2017 at 5:54:13 PM UTC+2, Eddie Ringle wrote:
>
> It's not particularly likely that cmd/compile/internal/gc will be
>> replaced by go/parser, go/ast, and friends.  The packages are
>> optimized in different ways for different purposes. 
>
>
> I was wondering about this separation as well. Is there an article or wiki 
> somewhre that expands on the reasoning behind it? It seems 
> counter-intuitive to essentially model the same tokenizer/parser/AST twice.
>
> On Wed, Jul 19, 2017 at 9:56 AM, Hajime Hoshi  > wrote:
>
>> Sorry for my super late reply, and thank you for answering!
>>
>> On Tue, Jun 27, 2017 at 12:41 AM Ian Lance Taylor > > wrote:
>>
>>> On Mon, Jun 26, 2017 at 2:39 AM, Hajime Hoshi >> > wrote:
>>> >
>>> > It looks like package cmd/compile/internal/gc includes tokenizer, 
>>> parser or
>>> > others for completion, and there are also other packages like 
>>> go/parser,
>>> > go/ast and so on for the same features. As gc code looks likes pretty 
>>> old
>>> > (this was converted from C at Go 1.5 AFAIR), will this be replaced 
>>> with go/*
>>> > packages in the future?
>>>
>>> It's not particularly likely that cmd/compile/internal/gc will be
>>> replaced by go/parser, go/ast, and friends.  The packages are
>>> optimized in different ways for different purposes.  It is likely that
>>> cmd/compile/internal/gc will continue to be rewritten and improved
>>> from its original C roots.  There was a lot of work on that in the 1.9
>>> cycle, and it will continue.
>>>
>>> Ian
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[go-nuts] Re: when has multi GOPATH, go can`t detect the vendor folder.

[Nathan Kerr]

By "has a vendor folder in it's root dir" do you mean 
/workspace/specific/project/vendor? 
If so, go didn't find it because that directory is outside of 
/workspace/specific/project/src/, and thus not seen as source files in the 
GOPATH. It works when the project is under /go because the vendor directory 
is below /go/src/.

On Friday, July 14, 2017 at 5:11:14 AM UTC+2, ganglin song wrote:
>
>
> In ~/.bash_profile , has a GOPATH Like this :
>
> export GOPATH=/go
>
>
>
> In the specific project ( *Not In GOPATH folder *), has a .env file Like 
> this:
>
>
> export GOPATH=`pwd`:$GOPATH
>  
>
> this .env file  makes current dir as a GOPTAH.
>
> After exec `source .env `, GOPATH becomes to this:
>
>
> go env
>
> 
> GOPATH=*/workspace/specific/project/*:/go
> 
>
>  
>
> Now , If this specific project has a vendor folder in it`s root dir , go 
> *cant`t 
> *detect the packages in this vendor folder.
>
> if move the whole project into the GOPATH (* /go , not the `pwd` *)， go* 
> can *recognize packages in vendor folder.
>

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

[go-nuts] Re: [Go2] toward-go2

[Nathan Kerr]

The active work for Go2 right now is gathering experience reports 
. Most of the changes resulting 
from these reports will land in Go1.x. It is expected that Go2 will only 
have a few major changes that will not be compatible with Go1. It is also 
possible there will be none (and Go1.20 will be called Go2)

The Go2 label in the issue tracker has meant, more or less, that the 
issue/proposal was something that could't be considered for Go1, usually 
because it would be the Go1 compatibility promise, but should be kept track 
of.

Apple didn't mention Swift because Apple doesn't mention things it is 
working on. Working in private and then releasing when things are ready is 
how Apple does things.

On Monday, July 17, 2017 at 5:42:34 AM UTC+2, Gert wrote:
>
> There are so many 
> https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+go2+label%3AGo2 
> proposals already I can barely figure out if feature x y or z is already 
> asked.
>
> Can we have a Go2 branch / milestone please? PS now that you announced 
> toward-go2 you are going to actively work on Go2 right? Its not some kind 
> of lets try to trick developers to keep using Go who are looking for 
> alternatives because they made a Go2 proposal many years ago and gave up 
> hope right? Don't get me wrong I love Go but I hate false promises or 
> making plans ridiculous far in the future. Not saying Go2 can't take a long 
> time to make, just saying i would like to see small bits of code emerging 
> on a weekly bases we can test and play around with and give feedback on 
> real things not just imaginary ideas :) If you can't make a Go2 branch yet 
> and more important things need to be done first on Go1 I understand 
> completely, but once you pull the Go2 card companies will pull back and 
> start waiting for Go2. Its the number one reason Apple didn't mention a 
> single word about Swift until they could deliver a fully functioning 
> compiler just because of that reasons to not jeopardise developers stop 
> learning objective c and waiting for Swift
>

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

[go-nuts] Re: Iterate trough interface{} that stores map

[Nathan Kerr]

If you know what the map type is, use a type assertion:

for k, v := range variable.(map[string]interface{}) {
   //... 
}

If it could be one of several map types, use a type switch first.

If you don't know anything about the map type, I don't know what you think 
you could do with it because you don't know what the data means.

On Monday, July 10, 2017 at 7:27:24 PM UTC+2, Kiageng satria pamungkas 
wrote:
>
> How to do that? i recently figure how to iterate interface{} that stores 
> slice but not map using refelct
>

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

[go-nuts] Re: display database table in html table like a gridview or dataview.

[Nathan Kerr]

For other readers of this thread:

This was solved in  Display database table in html table like gridview 

  
   


On Thursday, July 6, 2017 at 2:10:11 PM UTC+2, Connel blaze wrote:
>
> https://play.golang.org/p/QqHXewyDTp 
> This is what i have. It's a simple CRUD example I'm using to learn 
> go-database/sql. Create works fine but the 'Read' ain't working.
> When I goto the read route, it's a blank html page. No data. like the 
> struct isn't correct. 
> Is there something I'm missing?
>

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

[go-nuts] Re: Template func ParseFiles, parsing multiple files

[Nathan Kerr]

A text.Template contains one or more named templates. ParseFiles adds a new 
template to the collection with the filename as its name. Template names 
are used to tell Template.ExecuteTemplate 
 which of the 
included templates to execute.

On Thursday, July 6, 2017 at 6:37:01 AM UTC+2, Tong Sun wrote:
>
> What would it happen if I pass two or more files to:
>
> func (*Template) ParseFiles 
> 
> ❖ 
>
> func (t *Template ) 
> ParseFiles(filenames ...string ) (*Template 
> , error 
> )
>
> ParseFiles parses the named files and associates the resulting templates 
> with t. If an error occurs, parsing stops and the returned template is nil; 
> otherwise it is t. There must be at least one file. Since the templates 
> created by ParseFiles are named by the base names of the argument files, t 
> should usually have the name of one of the (base) names of the files. If it 
> does not, depending on t's contents before calling ParseFiles, t.Execute 
> may fail. In that case use t.ExecuteTemplate to execute a valid template.
>
> When parsing multiple files with the same name in different directories, 
> the last one mentioned will be the one that results.
>
> E.g., 
>
> What would the differences be that affects the output, for 
>
> MyTempl.ParseFiles(tf1)
>
> vs. 
>
> MyTempl.ParseFiles(tf1,tf2)? 
>
> Will the content of tf2 be appended to tf1? 
>
> Thx
>
>

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

Re: [go-nuts] How to access pointer to pointer in cgo

[Nathan Kerr]

Did you assign something to the pointer?

My guess is that you did not, because the code compiles and then fails at 
runtime telling the pointer is NULL.

On Wednesday, July 5, 2017 at 1:19:47 PM UTC+2, Manohar Reddy wrote:
>
> > fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
> MAGIC VARIABLE
>
> This line returns null pointer de-reference at run time. 
> Can you please guide me on how what is the  alternative for optional->_32
> ->Magic in Golang?
>
> Thanks
> On Wednesday, July 5, 2017 at 4:42:07 PM UTC+5:30, Jan Mercl wrote:
>>
>> On Wed, Jul 5, 2017 at 1:04 PM Manohar Reddy  wrote:
>>
>> > fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
>> MAGIC VARIABLE
>>
>> Who wants to guess what does "did not work for me" mean without having 
>> the source code and the compiler output to look at?
>>
>> Please post a complete example at eg. the Go playgound: 
>> https://play.golang.org/
>>
>> -- 
>>
>> -j
>>
>

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

[go-nuts] Re: Calling OS X dylib from Go

[Nathan Kerr]

The default gc toolchain is fine.

Use appropriate LDFLAGS or pkg-config directive in the import "C" comments. 
Then use the library like you would use any other library.

See the libpng example in the cgo documentation 
.

On Tuesday, July 4, 2017 at 9:20:32 PM UTC+2, Tejas Manohar wrote:
>
> Does anyone have examples or tips on calling methods from OS X dylib's 
> (dynamic, shared library) from Go? I have the C header file, too, but no 
> source code. Is it possible to call methods from the header file directly 
> in Go (alike a C program that `#include libproc.h`) or should I create a C 
> program in cgo-style comments with methods that call all the method 
> declarations in the header file and use that inline?
>
> Is gccgo recommended here? I'm building an OS X only program.
>

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

[go-nuts] Re: Go type chart

[Nathan Kerr]

Are you wanting something like https://github.com/gmarik/go-erd?

On Saturday, July 1, 2017 at 8:19:27 PM UTC+2, Tong Sun wrote:
>
> Hi, 
>
> Any exiting tools out there for Go type chart, to visualize the 
> relationships of different user defined Go types? Thx. 
>
>
>

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

[go-nuts] Re: How do you create and use shared libraries in Go?

[Nathan Kerr]

Go packages are usually source code published in web-accessible 
repositories such as GitHub. The repositories for packages you want to use 
are checked out/cloned into GOPATH 
 on your local machine using go 
get 
 
and 
the import path for that package 
.

Sharing a package you created is as easy as pushing the code for it to a 
web-accessible repository and making sure that imports of any packages in 
that repository use the full import path (e.g., 
github.com/username/pkgroot/pkg2).

Find packages at https://awesome-go.com and https://godoc.org (which also 
lets you see the documentation for any publicly-shared package).

On Monday, June 26, 2017 at 9:37:48 AM UTC+2, st ov wrote:
>
> Ruby has Gems and .NET has DLLs.
> How do you package and share libraries in Go?
>
>
>

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

[go-nuts] Re: How to Sync() a file?

[Nathan Kerr]

I assume that you mean by io.Copy not working correctly is that you expect 
the entire contents of File1.txt to be in File2.txt.

This does not happen in your code (without reopening f1) because Files 
maintain an offset inside the file that remembers where the next operation 
should take place. After calling f1.WriteString the offset is no longer at 
the beginning of the file, it is at the end of the written string.

To go to the beginning of the file, use File.Seek 
. For example: f1.Seek(0,0).

On Sunday, June 25, 2017 at 11:20:53 PM UTC+2, Farid Shahy wrote:
>
> Hi
> I have opened two files and want to use *io.Copy* to read from one file 
> and write to another, but it does not work.
> If I close first file and then reopen it* io.Copy* will work 
> correctly.Can anybody please help on this issue?
>
> f1, err := os.Create("File1.txt")
>> checkErr(err, "Error creating File1.txt")
>> // defer f1.Close()
>>
>> f2, err := os.Create("File2.txt")
>> checkErr(err, "Error creating File2.txt")
>> defer f2.Close()
>>
>> c1, err := f1.WriteString("Hello Pipe!")
>> checkErr(err, "Error writting to File1.txt")
>> fmt.Println("Written Count - f1: ", c1)
>>
>> err = f1.Sync()
>> checkErr(err, "Error writting File1.txt to disk.")
>>
>> // f1.Close()
>> // f1, err = os.OpenFile("File1.txt", os.O_RDWR, 0664)
>> // defer f1.Close()
>> // checkErr(err, "Error opening File1.txt again.")
>>
>> c2, err := io.Copy(f2, f1)
>> checkErr(err, "Error copying File1txt to File2.txt.")
>> fmt.Println("Written Count - f2: ", c2)
>>
>
> Thanks
> Farid Shahy
>

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

[go-nuts] Re: How can I make my own reader

[Nathan Kerr]

>From the docs :

Read reads up to len(p) bytes into p.


This lets the caller of Read manage the allocation and re-use of p. It also 
means your Read method has to work within the confines of whatever p you 
are given. If the data being read is larger than p, then the Read 
implementation must keep track of how much of the data has been read so 
far, and put the next part into p. 

On Sunday, June 25, 2017 at 8:39:58 PM UTC+2, 苏聪厚 wrote:
>
> package main
>
> import (
>"io"
>"log"
>"os"
> )
>
> type test struct {
>name string
> }
>
> func (a *test) Read(p []byte) (int, error) {
>
> var size int
>for {
>// I want to  put large data to response the read ; some data 
> whatever I want ...
>
> size = size + 102400
>// condition  to break
>break
>}
>
> return size, nil
> }
>
> func main() {
>r := &test{name: "test"}
>if _, err := io.Copy(os.Stdout, r); err != nil {
>log.Fatal(err)
>}
> }
>
>
> How Read method get its data , I do not know where my data should be put , 
> the method just return int 
>
>

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

[go-nuts] Re: godoc shows methods where they're not defined

[Nathan Kerr]

Since *conn is embedded in DirectLob, its method sets are promoted to 
DirectLob's method sets. Since BeginTx is now part of DirectLob's method 
sets, it acts like any other member of the method sets would; in this case 
it is an exported method on DirectLob.

This is a feature because it allows the use of *conn's methods while not 
allowing direct, external access to *conn. If you want to make only part of 
*conn's method sets available, don't embed *conn (i.e., give it a name) and 
write wrappers for the methods you need.

See https://golang.org/ref/spec#Struct_types for embedded field promotion 
rules.

On Sunday, June 25, 2017 at 9:51:01 AM UTC+2, Tamás Gulácsi wrote:
>
> Hi,
>
> Both my local go1.9-beta1, and godoc.org shows BeginTx on *DirectedLob, 
> but that's defined on *conn, a private type!
> What I'm doing wrong here?
>
> http://godoc.org/gopkg.in/goracle.v2
>
>
> Thanks,
> Tamás Gulácsi
>
>

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

Re: [go-nuts] go build for mips

[Nathan Kerr]

What system are you building on (OS and architecture)?

What version of Go are you using?

Is the result of running go build an illegal instruction?

What file did you provide information for?

What is in hello.go?

On Thursday, June 22, 2017 at 6:19:47 PM UTC+2, luc...@kryptus.com wrote:
>
> I try to build a simple hello world with
> cgo_enabled=1 goarch=mips goos=linux go build hello.go| Result: 
> illegal instruction 
>
> file information: ELF 32-bit MSB executable, MIPS, MIPS32 version 1 
> (SYSV), statically linked, not stripped
>
> Also, tried to build with another compile (CC=/path/to/Compiler) instead 
> the one go uses. Also illegal instruction 
> on my router tp-linkwdr3500.
>
> If anyone could give me a hint, I would be grateful.
>
> Thanks,
> Lucas.
>
>
> On Thursday, June 22, 2017 at 11:37:08 AM UTC-3, Ian Lance Taylor wrote:
>>
>> On Wed, Jun 21, 2017 at 7:48 PM, lucas.w...@gmail.com 
>>  wrote: 
>> > 
>> > Since go1.8 added support for mips32, why can't build a simple hello 
>> world 
>> > for a mips architecture system? 
>> > 
>> > I successfully build programs for arm architecture, but could not do 
>> the 
>> > same for mips. 
>>
>> Tell us precisely what you did and precisely what happened. 
>>
>> Ian 
>>
>

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

[go-nuts] Re: XML decoder vs xpath Performance

[Nathan Kerr]

Hi,

What is "best" depends on your exact situation. This includes the XML you 
receive, the specific values you need to extract, how much of the XML needs 
to be extracted, how much of the overall program the XML handling takes, 
the hardware the program runs on, and the development resources you have to 
use improving the XML handling.

Since you already have two implementations (Decoder and Manual), start by 
making sure they both work (by testing them) and then use benchmarks with 
-benchmem to find out which one you prefer.

If you don't know Go's benchmarking tools, checkout 
https://pocketgophers.com/concurrency-slower/ for an example I wrote that 
shows how they can be used to check for performance improvements.

On Monday, June 19, 2017 at 8:07:19 PM UTC+2, Abhijit Desai wrote:
>
> I need to integrateXML REST Api where dont need all the nodes / values 
> return by thirdparty REST Api
>
> There are main repeated 1500 nodes with lot of internal nodes
>
> Please let me know which I suppose to use performance wise
>
> 1. Xml Decoder
> 2. Manual by using Token()
> 3. XPath to get values
>
> Decoder and Manual both are taking 600 ms approx
>
> Please let me know best possible way to achieve this to use less Memory 
> with best performance
>
> Please help
>
> Rgds,
>
> Abhi
>
>
>
>
>
>

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

[go-nuts] Re: Is there any golang package available for building mongodb query from plain logic expression string or URL?

[Nathan Kerr]

I haven't tried it, but https://github.com/jhsx/qm might be useful.

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

[go-nuts] Re: did anyone tried // template exec ?

[Nathan Kerr]

I'm not aware of any templating languages that provide concurrent or 
parallel constructions.

If you need parallel execution of those function calls, I would run the 
calls as part of my Go code and then pass the results to the template.

On Tuesday, May 30, 2017 at 10:44:21 AM UTC+2, mhh...@gmail.com wrote:
>
> obviously not,
> go func t.Exec...
> go func t.Exec...
>
> but
>
> `
> {{slowcall}}
> {{fastcall}}
> {{slowcall}}
> {{$y := CanNot//}}
> `
>
> ect
>
> On Tuesday, May 30, 2017 at 10:09:35 AM UTC+2, mhh...@gmail.com wrote:
>>
>> hi,
>>
>> wonder, if anyone,
>> - tried to make an implementation of template that works in // ?
>> - was it successful ?
>> - useful for perf ?
>>
>> thanks
>>
>

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

Re: [go-nuts] Problem with HINDI NAMES

[Nathan Kerr]

The Go team knows this a problem (see the issues listed by Rob Pike). The 
difficultly in fixing it is that the ecosystem surrounding Go relies on the 
current definition for identifiers. There is no way to add the characters 
you need without breaking other tools like syntax highlighters. It is 
a socioeconomic problem than a technical one. The next time it can be fixed 
in Go is for Go 2.0 and is already on the list of issues to be considered.

If your main goal is to write programs in your language, you might consider 
using one from 
https://en.wikipedia.org/wiki/Non-English-based_programming_languages

On Friday, May 26, 2017 at 3:26:08 AM UTC+2, Vikram Rawat wrote:
>
> Hello Bakul,
>
> I am just an R programmer(by which i mean i don't understand programming 
> much). I was looking for an alternative way to python. I really don't 
> understand what you said but i want to let you all know one thing.
>
> English hasonly 26 characters but those are not sufficient for languages 
> like hindi, bengali, gurumukhi, malyalam and many other phonetic languages. 
> So we use entire keyboard to type letters.
>
> In the above example सोम is a proper word with a meaning we just simply 
> can't ignore ो or letters like that at all.
>
> Please tell me what to do. I really want to write program in my language 
> because there arenone written yet.
>
> Thanks for any reply you give me
>
> Regards from India,
>
> Vikram singh Rawat
>
>
> On 26-May-2017 5:44 am, "Bakul Shah" > 
> wrote:
>
> In my view, in the "worse is better" unix tradition, you can leave 
> "canonicalization" out. Let the user worry about that (different ways of 
> representing such chars can be checked and warned about by a lint program). 
> Then the compiler only need to allow additional runes that pass 
> unicode.IsMark() for all but the first rune of an identifier. [Would be 
> nice if we didn't have to wait for the mythical 2.0 for this!]
>
> As for exporting symbols, prepending _ for making symbols private means 
> most likely more symbols will get accidentally exported. Once leaked they 
> are harder to unleak! The default should be to keep things private. Why not 
> instead allow an explicit "export" section?
>
> On May 25, 2017, at 12:37 PM, Rob Pike > 
> wrote:
>
> This is https://github.com/golang/go/issues/5167.
>
> See also https://github.com/golang/go/issues/16033.
>
> -rob
>
>
> On Fri, May 26, 2017 at 1:15 AM, Bakul Shah  > wrote:
>
>> In other words, you should file a bug report (but technically it is a 
>> language change).
>>
>> For Go purposes an identifier should start with unicode letter or 
>> underscore as now but for the following Unicode chars the rule should be 
>> extended to include chars matching Unicode categories space combining (Mc) 
>> and nonspacing (Mn) mark.
>>
>> On May 25, 2017, at 7:47 AM, Bakul Shah > > wrote:
>>
>> As per the language ref technically this is not a bug as a vowel sign 
>> (U+094B 
>> 'ो') is a not Unicode letter but practically it is since you the 
>> majority of words in Indic languages need them.
>>
>> On May 24, 2017, at 11:14 PM, Vikram Rawat > > wrote:
>>
>> package main
>>
>> import (p"fmt"
>>
>> )
>> func main(){
>> सोम(1,1,1,21323,2,2,32,1,)
>>
>>
>> }
>>
>> func सोम (num ...int){
>> var total int
>> for _, r:= range num{
>> total = total + r
>> }
>> p.Println("तुन्हारा जोड़ है ",total)
>> }
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>

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

[go-nuts] Go 1.8.3 is released

[Nathan Kerr]

Thanks for the hard work.

I updated my Go Release Timeline: 
https://pocketgophers.com/go-release-timeline/#go1.8.3

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

[go-nuts] Re: [security] Go 1.7.6 and Go 1.8.2 are released

[Nathan Kerr]

I updated my Go Release Timeline with these updates:

https://pocketgophers.com/go-release-timeline/#go1.8.2

On Tuesday, May 23, 2017 at 9:28:01 PM UTC+2, Chris Broadfoot wrote:
>
> A security-related issue was recently reported in Go's crypto/elliptic 
> package.
> To address this issue, we have just released Go 1.7.6 and Go 1.8.2.
>
> The Go team would like to thank Vlad Krasnov and Filippo Valsorda at 
> Cloudflare for reporting the issue and providing a fix.
>
> The issue affects Go's P-256 implementation on the 64-bit x86 architecture.
>
> This is CVE-2017-8932 and was addressed by this change: 
> https://golang.org/cl/41070, tracked in this issue: 
> https://golang.org/issue/20040
>
> Downloads are available at https://golang.org/dl for all supported 
> platforms.
>
> We will be releasing Go 1.8.3 later today, which will additionally include 
> some non-security fixes.
>
> Cheers,
> Chris (on behalf of the Go team)
>

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

[go-nuts] Re: Feedback welcome: "Shorten your URL"

[Nathan Kerr]

There are also responses here:  Feedback Welcome: ‘Shorten your URL’   
   


On Tuesday, May 2, 2017 at 9:32:45 AM UTC+2, Lutz Horn wrote:
>
> Hi Go Nuts, 
>
> to practice my Go skills, I've implemented a simple web application that 
> allows you to shorten an URL. The application consists of a backend 
> written in Go and a web frontend using jQuery with some plugins and 
> Bootstrap for layout. 
>
> The code is available on GitHub at https://github.com/lutzhorn/shorturl, 
> the application is deployed on https://u.lhorn.de. 
>
> I would very much appreciate any feedback you can give especially on the 
> Go part. Coming from a Java and Python background, I'm trying to get 
> into the Go way of programming, In Python there is a 'Pythonic' way to 
> write code, I am sure there is something similar in Go: File structure, 
> name choice, exporting names, error handling, ... 
>
> If you have a little time, please tak a look at the code, play with the 
> deployed application, and please give me feedback. 
>
> Thanks! 
>
> Lutz 
>
>
>

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

[go-nuts] Fully-qualified import paths and Pull Requests

[Nathan Kerr]

http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives some good 
pointers on how to do this.

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

[go-nuts] openid connect

[Nathan Kerr]

Try using https://github.com/markbates/goth

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

[go-nuts] Re: Dynamic type assertion for interface

[Nathan Kerr]

Thanks for providing code!

What is CopyStruct intended to do?

On Monday, April 24, 2017 at 6:33:58 PM UTC+2, Rajesh kumar wrote:
>
> Please do note that the structs in this example is a sample.My struct is 
> complex than this.
> https://play.golang.org/p/_t7gx3javb 
> Here I have a function where i will be using lot of times.Each time i will 
> be passing object of different struct types.So i use the parameter 
> arguments as interface{}. So to solve the error i need to do type 
> assertion.But here the interface can be of any struct type.So i am looking 
> if there is any possible way to do the dynamic type assertion based on the 
> reflect.TypeOf value.
>

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

Re: [go-nuts] Link documentation sources

[Nathan Kerr]

All the package documentation on https://golang.org/pkg and 
https://godoc.org is generated from the source.

The headers for functions, types, etc. link to the source line where the 
function, type, etc. was defined.

You can read more about godoc 
 (the documentation 
generation tool) and godoc.org  (the hosting 
site).


On Tuesday, April 18, 2017 at 6:14:12 AM UTC+2, anatoly techtonik wrote:
>
> It still would be nice to trace back to these sources to fix them, 
> and describe the syntax for cross-linking. 
>
> On Tue, Apr 18, 2017 at 4:30 AM, Stas Maksimov  > wrote: 
> > I believe this documentation is built from comments in the source code: 
> > https://go.googlesource.com/go/+/go1.8.1/src/path/path.go 
> > 
> > S. 
> > 
> > On Mon, 17 Apr 2017 at 20:49 anatoly techtonik  > wrote: 
> >> 
> >> On Monday, April 17, 2017 at 7:35:00 PM UTC+3, Jan Mercl wrote: 
> >>> 
> >>> On Mon, Apr 17, 2017 at 5:45 PM anatoly techtonik  
> >>> wrote: 
> >>> 
> >>> > I want to see documentation sources for this page - 
> >>> > https://golang.org/pkg/path/#pkg-overview 
> >>> > Why there is no link to them in the footer, like on 
> >>> > https://readthedocs.org/? 
> >>> 
> >>> What do you mean by 'documentation sources'? 
> >> 
> >> 
> >> https://cilium.readthedocs.io/en/latest/intro/ - see the Edit on 
> Github 
> >> link in top right corner. 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "golang-nuts" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to golang-nuts...@googlegroups.com . 
> >> For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> anatoly t. 
>

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

[go-nuts] Re: http.Server handlers seem to stick around forever

[Nathan Kerr]

Instead of trying to restart the server, switch the handler:

package main

import (
"fmt"
"io/ioutil"
"log"
"net/http"
"strconv"
)

// Some state so we can show the old handler is in effect...
type Foo struct {
SomeVar int
}

func (f *Foo) ServeHTTP(w http.ResponseWriter, r *http.Request) {
fmt.Printf("In handler wrapper, f = %p\n", f)
w.Write([]byte(strconv.Itoa(f.SomeVar)))
}

type switchable struct {
h http.Handler
}

func (s *switchable) ServeHTTP(w http.ResponseWriter, r *http.Request) {
s.h.ServeHTTP(w, r)
}

func main() {
log.SetFlags(log.Lshortfile)

f1 := &Foo{SomeVar: 1}
f2 := &Foo{SomeVar: 2}

handler := &switchable{f1}

go func() {
log.Fatalln(http.ListenAndServe("0.0.0.0:8090", handler))
}()

fmt.Println(doRequest())

handler.h = f2

fmt.Println(doRequest())
}

func doRequest() string {
client := &http.Client{}
req, err := http.NewRequest("GET", "http://0.0.0.0:8090";, nil)
if err != nil {
log.Fatalln(err)
}

resp, err := client.Do(req)
if err != nil {
log.Fatalln(err)
}

bytes, err := ioutil.ReadAll(resp.Body)
if err != nil {
log.Fatalln(err)
}

return string(bytes)
}

Output:
$ go run main.go
In handler wrapper, f = 0xc420060fa0
1
In handler wrapper, f = 0xc420060fa8
2

I'm not sure if there is a race condition here or not...

On Tuesday, April 18, 2017 at 7:02:17 AM UTC+2, Ken Simon wrote:
>
> Hello golang-nuts!
>
> I have some code that creates a short-lived HTTP server, and I'm trying to 
> write tests for it.  I'm hitting a case where HTTP handlers seem to stick 
> around even though I'm creating a brand new `http.ServeMux`, `http.Server`, 
> and `net.Listener` objects.  How do I get rid of old handlers?
>
> Here's a semi-simple reproducible case:
>
> package main
>
> import (
> "fmt"
> "io/ioutil"
> "net"
> "net/http"
> "os"
> "strconv"
> "time"
> )
>
> // Some state so we can show the old handler is in effect...
> type Foo struct {
> SomeVar int
> }
>
> func (f *Foo) Serve(addr string) (net.Listener, error) {
> l, err := net.Listen("tcp", addr)
> if err != nil {
> return nil, err
> }
> mux := http.NewServeMux()
> mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
> fmt.Printf("In handler wrapper, f = %p\n", f)
> w.Write([]byte(strconv.Itoa(f.SomeVar)))
> })
> srv := &http.Server{
> Handler: mux,
> }
>
> go srv.Serve(l)
> return l, nil
> }
>
> func main() {
> f1 := &Foo{SomeVar: 1}
> f2 := &Foo{SomeVar: 2}
>
> l, err := f1.Serve("0.0.0.0:8090")
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
> fmt.Println(doRequest())
> l.Close()
> // Ok it didn't actually close, wait a bit or it'll show the address as
> // already in use...
> time.Sleep(1 * time.Second)
>
> l, err = f2.Serve("0.0.0.0:8090")
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
> fmt.Println(doRequest())
> l.Close()
> }
>
> func doRequest() string {
> client := &http.Client{}
> req, _ := http.NewRequest("GET", "http://0.0.0.0:8090";, nil)
> resp, _ := client.Do(req)
> bytes, _ := ioutil.ReadAll(resp.Body)
> return string(bytes)
> }
>
> Output:
>
> $ go run main.go
> In handler wrapper, f = 0xc42000d200
> 1
> In handler wrapper, f = 0xc42000d200
> 1
>
> Note the pointer to the method receiver is the same in both cases, 
> indicating the old ServeMux is still handling the new request... (boy did 
> it take me a long time to figure out what was going on in a non-trivial 
> codebase...)
>
> What's happening here?  Is the old http.Server still "attached" to the 
> tcp.Listener?  What can I do to fix this?
>
> Thanks so much!
>

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

[go-nuts] Re: Go 1.8.1 is released

[Nathan Kerr]

Thanks for all the hard work!

I have updated my go release timeline 
 visualization.

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

[go-nuts] Re: Error checking and defer

[Nathan Kerr]

I prefer to accept that multiple errors can occur. 
https://pocketgophers.com/handling-errors-in-defer/

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

Re: [go-nuts] Re: Conserving memory in TLS handshake and x509 certificate verification

[Nathan Morley]

>
> What cgo calls were those? Are you using an alternative crypto
> implentation?


Sadly, I didn't save any of the metrics I gathered any more, so I can't say
specifically what CGO calls were being used by my application. I do recall
a good bit of the memory being spent on checking the certificate with the
system the application was running on... but my memory is foggy after a
long day.

I was not using any alternative crypo implemenations. Straight out of the
box native http.Client with no alterations.

Also quite curious about this. My assumption was that all resources should
> eventually be cleaned up when http.Client goes out of scope?


...Honestly, I'm not sure entirely what was going on, as I'm not too
familiar with Go's GC. Running my build with -gcflags -m shows that the
HTTP client in question is escaping to the heap. My expectation was also
that it would be cleared eventually. From what I could tell from profiling
and a few other things, the memory gets allocated to the application and
*maybe* gets released back to the application, but not the host. I say
maybe because profiling does not get everything, and upon profiling I would
see about 300mb being used but my host (again, Windows) was showing
500mb-1.3gb being dedicated at the same time. Now, why this memory doesn't
get reused by the application is, frankly, a mystery to me. It seems to
just provision more and more, even though it doesn't need it.

If you want to replicate... My setup essentially had multiple goroutines
calling a single method that creates a new http.Client with every call to
execute the request. No extra configuration, no customized TLS, just your
basic &http.Client{} or something similar. The only thing you need to do is
ensure that the client uses HTTPS. I also used a Redis client for the job
queue and Mongo for the database, but the resources used there were
negligible in comparison.

If you want something you can throw the might of Go at without having to
worry about rate limiting, here's the home page for the API
 I was consuming in this case. Only thing
you have to worry about is obeying cache rules from the headers.

And no, I wasn't using swagger... mostly because windows doesn't like long
file paths.

With that setup, and 5 worker threads, I would quickly reach 300-500mb
withing a few minutes, and peak at 1.2-1.3gb before it would stop
functioning entirely.

Ultimately, it just comes down to me doing a quick-n-dirty setup without
really thinking. I  fixed it by making a client that is reused for every
call, and happily sit at 9-12mb in memory without issue.

P.S. Roughly the same application didn't have this issue on older Go
versions... 1.8 is when I really started noticing it. Possibly a new bug?

P.S.S. Sorry for typos/grammar etc... long day and the T key is acting up.

On Wed, Mar 15, 2017 at 10:11 PM, Tom  wrote:

> Also quite curious about this. My assumption was that all resources should
> eventually be cleaned up when http.Client goes out of scope?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/DIXihO2sLRE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: Conserving memory in TLS handshake and x509 certificate verification

[Nathan Morley]

Problem resolved. Application was allocating a new http.Client for every 
remote call made, and since the handshake ultimately comes down to CGO 
calls, I was accumulating memory that was not managed by Go's GC.

On Tuesday, March 14, 2017 at 8:21:58 PM UTC-4, Nathan Morley wrote:
>
> Hello,
>
> So I've written a small service in my free time that essentially pulls 
> data from a RESTful API at a high rate, and store it in a database. While 
> there is no rate limiting in place and I'm free to hit it as hard as I like 
> with as many connections I need, I only have 5 workers going at a time that 
> actively hit the API.
>
> I started noticing that the application quickly allocates/uses a fair bit 
> of memory than I would have suspected for such a simple use case. so I set 
> up profiling via the pprof tool to see what is going on. I found no real 
> issue with my own code, but it looks like my http.Client is the primary 
> offender for me. Particularly, the handshake and in parsing the x509 
> certificate.
>
> While it is probably more than reasonable to see this, given what is 
> involved, I'm wondering if there might be something I can do to bring down 
> the application's overhead?
>
> I also may be reading in to this too hard, as well. But my end goal is to 
> have this application out of my development environment and on my server, 
> which is already somewhat limited in resources.
>
> I can provide the pprof graph if it would.
>
> TL;DR
>
> I wrote a small application that hits a RESTful API really hard, but 
> doesn't do much else. I'm noticing a lot of memory being used by the TLS 
> handshake and in parsing the x509 certificate.
>
> Does anyone have suggestions on how I might improve this, or thoughts on 
> what I might be doing wrong here?
>
> For the record, this is on a Windows PC, and I have not tested for this on 
> my server, which runs on Linux.
>
>

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

[go-nuts] Conserving memory in TLS handshake and x509 certificate verification

[Nathan Morley]

Hello,

So I've written a small service in my free time that essentially pulls data 
from a RESTful API at a high rate, and store it in a database. While there 
is no rate limiting in place and I'm free to hit it as hard as I like with 
as many connections I need, I only have 5 workers going at a time that 
actively hit the API.

I started noticing that the application quickly allocates/uses a fair bit 
of memory than I would have suspected for such a simple use case. so I set 
up profiling via the pprof tool to see what is going on. I found no real 
issue with my own code, but it looks like my http.Client is the primary 
offender for me. Particularly, the handshake and in parsing the x509 
certificate.

While it is probably more than reasonable to see this, given what is 
involved, I'm wondering if there might be something I can do to bring down 
the application's overhead?

I also may be reading in to this too hard, as well. But my end goal is to 
have this application out of my development environment and on my server, 
which is already somewhat limited in resources.

I can provide the pprof graph if it would.

TL;DR

I wrote a small application that hits a RESTful API really hard, but 
doesn't do much else. I'm noticing a lot of memory being used by the TLS 
handshake and in parsing the x509 certificate.

Does anyone have suggestions on how I might improve this, or thoughts on 
what I might be doing wrong here?

For the record, this is on a Windows PC, and I have not tested for this on 
my server, which runs on Linux.

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

[go-nuts] Re: fsnotify: maintainers wanted

[Nathan Youngman]

I'm stepping away from the fsnotify project.

Maintainers 
wanted: https://github.com/fsnotify/fsnotify/issues/183#issuecomment-286456045

Good luck,
Nathan.

On Tuesday, 25 October 2016 12:09:48 UTC-6, Nathan Youngman wrote:
>
> Hi,
>
> Fsnotify provides notifications of changes to files and directories on 
> BSD, Linux, Mac, and Windows. It is  imported by ~800 projects (via 
> godoc.org).
>
> While I would like to remain involved in fsnotify, I personally don't have 
> enough cycles to handle all the incoming issues and pull requests coming 
> into fsnotify.
>
> It's a challenging project to work on, partially because it is 
> cross-platform, trying to present a common API for operating system calls 
> that are very different in behaviour. To address this, the best solution I 
> can come up with is to split fsnotify into several platform-specific 
> libraries. Each library would manage the low-level details of file system 
> monitoring on that platform. With those libraries in place, the fsnotify 
> library can then turn its focus to the higher level abstractions by 
> depending on the low-level libraries.
>
> Those low-level libraries could also offer more complete APIs when 
> fsnotify's lowest common denominator solution is insufficient, as well as 
> provide a foundation for alternatives to fsnotify.
>
> This won't be possible without people stepping up to lead and maintain 
> libraries for each platform. This is a call for help in making the fsnotify 
> project better for gophers everywhere. It will involve low-level code, 
> research, integration tests, documentation, helping investigate and address 
> issues, code reviews, and more.
>
> If you're interested, please get involved. The related GitHub issue is 
> here: https://github.com/fsnotify/fsnotify/issues/183
>
> Thanks,
> Nathan.
>
>

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

Re: [go-nuts] Re: Understanding garbage collection in Go with infinite lists

[Nathan Fisher]

Hi Yota,

I don't disagree there's value in understanding how Go handles the
scenario. What I'm not certain of is the potential tradeoffs when
optimising for an uncommon edge case.

The loop you've created is very tight and would be unusual to find in a
typical application. The allocator is moving faster than GC could ever hope
to keep up. Given it's an endless loop without any work I think there would
be a tradeoff of performance to guard against something that will only
exist in micro-benchmarks and/or invalid code.

I would expect that if you introduce some "work" the memory leak would go
away.

Kind regards,
Nathan

On Fri, 3 Mar 2017 at 01:10 Yota Toyama  wrote:

Volker,

I don't know if the term "memory leak" is misuse.
But, the 1st version's memory usage is constant but the 2nd version's one
grows over time as if nothing is garbage-collected.


Yota


On Friday, March 3, 2017 at 2:38:08 AM UTC+9, Volker Dobler wrote:

Am Donnerstag, 2. März 2017 17:15:05 UTC+1 schrieb Yota Toyama:

Hi, all.

I'm trying to understand argument liveness in Go 1.8.
As preparation for it, I wrote 2 programs which iterate over infinite lists.
At first, I thought both can be run forever without any memory leak.
However, the result was that one could and the other couldn't.

Their main difference is the way to iterate lists.

l := *NewList(42, nil)

for {
  l = *l.Rest() // Cause no memory leak :)
}

vs

l := NewList(42, nil)

for {
  l = l.Rest() // Cause memory leak!!!
}

The repository is here <https://github.com/raviqqe/argument-liveness.go>.
I wanna understand why the latter causes memory leak and what is going on
in my programs at low level.
Any ideas?



What makes you say that one version causes a memory leak?

The first version produces much less garbage (well, basically none):
l is a ListValue and the freshly created "list rest" is assigned to it,
basically just overwriting the memory location of l with the same
value.

The second version produces an endless linked list where only the
last list element is reachable from your code as this is the only value
you have a pointer to.

So the second produces tremendous amounts of  garbage but this
garbage is collectable. Running it shows no problem when tracing GC
at least not with Go 1.8.

So the main difference is: The first code does not produce an "endless
list" it just operates on one List value while the second code really
constructs an ever increasing linked list if List values where only the
tail is reachable/uncollectable.

How did you determine the second version "leaks"?

V

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

-- 
- from my thumbs to your eyes

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

[go-nuts] Re: NewTicker function example

[Nathan Kerr]

The example I gave already runs forever. No need for select.

As for daemonization, I have had good luck with github.com/jpillora/overseer
.

On Friday, February 24, 2017 at 1:22:36 AM UTC+1, Keith Brown wrote:
>
> Thank You all for the great examples!
>
> I added a select {} at the end so the program will run forever. I am 
> trying to have it as a deamon.
>
>
>
> On Thursday, February 23, 2017 at 6:37:12 AM UTC-5, Nathan Kerr wrote:
>>
>> NewTicker function example
>>
>> The task of running functions on a periodic basis can be split into two 
>> parts: timing and execution.
>>
>> A ticker solves the timing problem by providing a channel that get new 
>> input every period. Keeping the timing separate mitigates the impact of 
>> execution on the timing period (e.g., it won’t be execution time + sleep 
>> time)
>>
>> Execution can be solved by ranging over the ticker channel. The contents 
>> of the loop will be run for each input received from the ticker channel. If 
>> the loop executes in less than one period, the loop will execute every 
>> period.
>>
>> Since tickers use channels, the execution loop can be run anywhere, 
>> though they are frequently used in goroutines because the program is also 
>> doing something else.
>>
>> I would simplify Rodolfo’s examples to:
>>
>> package main
>>
>> import (
>> "fmt"
>> "time"
>> )
>>
>> func square(x int) int {
>> return x * x
>> }
>>
>> func cube(x int) int {
>> return x * x * x
>> }
>>
>> func main() {
>> ticker := time.NewTicker(5 * time.Second)
>>
>> for range ticker.C {
>> fmt.Println(square(10))
>> fmt.Println(cube(10))
>> }
>> }
>>
>> This will run square and cube every 5 seconds while the program is 
>> executing.
>>
>> On Thursday, February 23, 2017 at 2:39:12 AM UTC+1, Keith Brown wrote:
>>>
>>> Oddly, I can't find a single example on the world wide web for what I am 
>>> trying to do.
>>>
>>> I have 2 functions which I want to run on a periodic basis. The 
>>> functions are square and cube. 
>>> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
>>> But, I am not sure how to schedule these functions.  I looked here, 
>>> https://gobyexample.com/tickers, but really isn't that helpful or 
>>> intuitive. 
>>>
>>>
>>>
>>>

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

Re: [go-nuts] Re: Trying to understand := and named return values

[Nathan Kerr]

They also seem to be the only way to handle errors in defer 
 without panic or 
log.Fatal.

On Wednesday, February 22, 2017 at 6:24:41 AM UTC+1, Paul Borman wrote:
>
> Named return values are perfectly fine, and I agree, probably should not 
> be discouraged.  For example, which is easier to write documentation for?
>
> func Run(cmd string) ([]byte, []byte, error)
>
> func Run(cmd string) (stdout, stderr []byte, _ error)
>
> What is not good is the following function:
>
> func Foo() (err error) {
> if err := someFunc(); err != nil {
> return  // Why do I always get a nil error?!?!
> }
> return
> }
>
> This is a* naked return* and that is what is bad, not that you named your 
> return values.   This version is fine:
>
> func Foo() (err error) {
> if err := someFunc(); err != nil {
> return  err
> }
> return nil
> }
>
> As there is no doubt on what is being returned.  And as mentioned earlier, 
> named returns are very useful in defers:
>
> func Foo(path string) (err error) {
> w, err := os.Create(path, 0644)
> if err != nil {
> return err
> }
> defer func() {
> if cerr := w.Close(); cerr != nil && err == nil {
> err = cerr
> }
> }()
> ...
> }
>
>
> Again, named return values are fine and cause no problems, but naked 
> returns should never have been part of the language (at first they seem 
> useful and cool, but in the end, they cause more problems than they solve).
>
> On Tue, Feb 21, 2017 at 8:25 PM, > wrote:
>
>> Named returns are actually quite useful with panics :
>>
>> https://play.golang.org/p/ZdoZJBN0T1
>>
>>
>> Le mardi 21 février 2017 23:13:11 UTC+1, Ian Lance Taylor a écrit :
>>>
>>> On Tue, Feb 21, 2017 at 1:46 PM,   wrote: 
>>> > Seems like named returns + if/for/switch initializers = a shadowing 
>>> > nightmare. I wish the Go compiler emitted a loud warning on shadowing, 
>>> as 
>>> > this is a dangerously subtle problem out there. 
>>>
>>> Yes, named returns may have been a mistake.  Only use them in very 
>>> very short functions. 
>>>
>>> Ian 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[go-nuts] Re: NewTicker function example

[Nathan Kerr]

NewTicker function example

The task of running functions on a periodic basis can be split into two 
parts: timing and execution.

A ticker solves the timing problem by providing a channel that get new 
input every period. Keeping the timing separate mitigates the impact of 
execution on the timing period (e.g., it won’t be execution time + sleep 
time)

Execution can be solved by ranging over the ticker channel. The contents of 
the loop will be run for each input received from the ticker channel. If 
the loop executes in less than one period, the loop will execute every 
period.

Since tickers use channels, the execution loop can be run anywhere, though 
they are frequently used in goroutines because the program is also doing 
something else.

I would simplify Rodolfo’s examples to:

package main

import (
"fmt"
"time"
)

func square(x int) int {
return x * x
}

func cube(x int) int {
return x * x * x
}

func main() {
ticker := time.NewTicker(5 * time.Second)

for range ticker.C {
fmt.Println(square(10))
fmt.Println(cube(10))
}
}

This will run square and cube every 5 seconds while the program is 
executing.

On Thursday, February 23, 2017 at 2:39:12 AM UTC+1, Keith Brown wrote:
>
> Oddly, I can't find a single example on the world wide web for what I am 
> trying to do.
>
> I have 2 functions which I want to run on a periodic basis. The functions 
> are square and cube. 
> Here is my code so far. https://play.golang.org/p/akMxcg2Sra
> But, I am not sure how to schedule these functions.  I looked here, 
> https://gobyexample.com/tickers, but really isn't that helpful or 
> intuitive. 
>
>
>
>

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

[go-nuts] Re: unexpected end of JSON input while unmarshal to struct

[Nathan Kerr]

I assume you mean that you didn't know that json.Unmarshal would call 
*LimitOrder.UnmarshalJSON because *LimitOrder.UnmarshalJSON explicitly 
calls json.Unmarshal.

If so, I also had not realized the significance of the UnmarshalJSON 
<https://godoc.org/encoding/json#Unmarshaler> name. This is one of the 
hazards of implicit interfaces.

On Thursday, February 23, 2017 at 2:48:22 AM UTC+1, Diogo Ribeiro wrote:
>
> Thanks Nathan, it worked.
> I didn't know that *LimitOrder.UnmarshalJSON would call json.Unmarshal.
>
> Em terça-feira, 21 de fevereiro de 2017 05:24:45 UTC-3, Nathan Kerr 
> escreveu:
>>
>> I figured it out.
>>
>> First off, the posted playground had a different json string and did not 
>> use your UnmarshalJSON function. These made translating between the 
>> non-working setup described in your post and the working playground 
>> annoying. In the future, share the non-working setup.
>>
>> At the point when I figured things out, my code was: 
>> https://play.golang.org/p/aMvz_JTrjD. This won't run on playground 
>> because it uses github.com/pkg/errors to add context to the errors so I 
>> could see which error was returned along with a much needed stack trace.
>>
>> I found two problems with the implementation of UnmarshalJSON:
>>
>> 1. tmp["response_data"] and tmp2["order"] return zero values when the key 
>> is not found. This happened, first, because of the difference between the 
>> posted json and the json in the posted playground. Second, because of the 
>> second problem.
>>
>> 2. json.Unmarshal uses a type's UnmarshalJSON function if it exists to do 
>> the unmarshalling. This created a loop where *LimitOrder.UnmarshalJSON 
>> calls json.Unmarshal, which calls *LimitOrder.UnmarshalJSON, and so on. 
>> Line 71 prints out the call stack for the returned error that confirms this.
>>
>> My recommended way of doing things is 
>> https://play.golang.org/p/kRKevuX8LW, that is write out the structs you 
>> need. This will also allow you to check the status_code from the response. 
>> If your LimitOrder will outlive the response then change 
>> ResponseData.LimitOrder to be a pointer.
>>
>> Hope this helps.
>>
>> On Tuesday, February 21, 2017 at 6:25:10 AM UTC+1, Diogo Ribeiro wrote:
>>>
>>> Could you help me to understand why I'm always getting the error unexpected 
>>> end of JSON input while trying to unmarshal the following json to the 
>>> LimitOrder struct? It works if I use golang playground 
>>> https://play.golang.org/p/udPQ_TayXG but not locally running tests.
>>>
>>>
>>> P.S.: if I use map[string]json.RawMessage instead of LimitOrder struct 
>>> I'm able to execute the unmarshal.
>>>
>>>
>>> {
>>>   "response_data": {
>>> "order": {
>>>   "order_id": 3,
>>>   "coin_pair": "BRLBTC",
>>>   "order_type": 1,
>>>   "status": 4,
>>>   "has_fills": true,
>>>   "quantity": "1.",
>>>   "limit_price": "900.0",
>>>   "executed_quantity": "1.",
>>>   "executed_price_avg": "900.0",
>>>   "fee": "0.0030",
>>>   "created_timestamp": "1453835329",
>>>   "updated_timestamp": "1453835329",
>>>   "operations": [
>>> {
>>>   "operation_id": 1,
>>>   "quantity": "1.",
>>>   "price": "900.0",
>>>   "fee_rate": "0.30",
>>>   "executed_timestamp": "1453835329"
>>> }
>>>   ]
>>> }
>>>   },
>>>   "status_code": 100,
>>>   "server_unix_timestamp": "1453835329"}
>>>
>>> *LimitOrder struct*
>>>
>>>
>>> type LimitOrder struct {
>>>   OrderId int `json:"order_id"`
>>>   CoinPair string `json:"coin_pair"`
>>>   OrderType int `json:"order_type"`
>>>   Status int `json:"status"`
>>>   HasFills bool `json:"has_fills"`
>>>   Quantity float64 `json:"quantity,string"`
>>>   LimitPrice float64 `json:"limit_price,string"`
>>

Re: [go-nuts] Initializing nested struct, by dynamically forming struct member path

[Nathan Kerr]

You gave two different things you want to accomplish:

1. “I am trying to read those values and store in DB”
2. “I will populate the struct and provide it the application for 
consumption”

Fortunately accomplishing either or both of these goals follows a similar 
process.

Start by figuring out what the output should be. In the case of a DB, the 
schema the data will be put into. For providing it to the application, the 
data structures you want. You mentioned using range, which means the data 
you want to range over needs to be in a slice or a map.

Then extract and transform the input into the output.

Some guesses I have made about your data:

- There are a variable number of applications and their names aren’t known 
before you get the data.
- Applications have different parameters
- Parameter types default to the contents of “parameterType”, in this case 
“common”

Assuming these guesses are correct, I would unmarshal the json into:

struct {
JsonData []struct {
DataReference []struct {
ParameterType   string `json:"parameterType"`
ApplicationType map[string]map[string]interface{}
} `json:"dataReference"`
} `json:"jsondata"`
}

This sets out the known portions and leaves the variable portions for later 
handling.

Then iterate over ApplicationType to get the different applications and 
their parameters. Populate the database or desired data structures during 
the loop.

An example of this process: https://play.golang.org/p/TNYur-Lr2Z 

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

[go-nuts] Re: Import path search order?

[Nathan Kerr]

GOPATH is a list 
<https://golang.org/cmd/go/#hdr-GOPATH_environment_variable>, though it 
usually only contains one element. The first element in the list is the 
leftmost one (e.g., GOPATH=first:second:last).

GOROOT holds the standard library, so those packages must be findable. The 
standard library is distributed as source.

On Tuesday, February 21, 2017 at 5:51:10 PM UTC+1, so.q...@gmail.com wrote:
>
> Thanks! 
>
> what do you mean by "from left to right"?
> And by GOROOT, you mean it looks at the go source?
>
>
>
> On Tuesday, February 21, 2017 at 1:27:59 AM UTC-8, Nathan Kerr wrote:
>>
>> Relative package don't need to be searched for, they are explicit 
>> (indicated with ./ or ../)
>>
>> Then it seems to be:
>>
>> 1. vendor tree, if it exists
>> 2. GOROOT
>> 3. GOPATH, from left to right
>>
>> Trying to build a package with an import that cannot be found will 
>> display an error listing all the locations it looked for the package. To 
>> get the vendor tree listed, a vendor directory must exist in the package 
>> you are trying to build.
>>
>>
>> On Tuesday, February 21, 2017 at 3:01:59 AM UTC+1, so.q...@gmail.com 
>> wrote:
>>>
>>> What is the search order for the import path?
>>> for example, relative then vendor then workspace?
>>>
>>>
>>>

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

Re: [go-nuts] Initializing nested struct, by dynamically forming struct member path

[Nathan Kerr]

Could you give an example of the json you are starting from?

Also, what database are you using?

On Sunday, February 19, 2017 at 8:27:32 AM UTC+1, Bharath B wrote:
>
> Hi,
>
> I am trying to read those values and store in DB.
>
> Regards,
> Bharath B
>

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

[go-nuts] Re: Import path search order?

[Nathan Kerr]

Relative package don't need to be searched for, they are explicit 
(indicated with ./ or ../)

Then it seems to be:

1. vendor tree, if it exists
2. GOROOT
3. GOPATH, from left to right

Trying to build a package with an import that cannot be found will display 
an error listing all the locations it looked for the package. To get the 
vendor tree listed, a vendor directory must exist in the package you are 
trying to build.


On Tuesday, February 21, 2017 at 3:01:59 AM UTC+1, so.q...@gmail.com wrote:
>
> What is the search order for the import path?
> for example, relative then vendor then workspace?
>
>
>

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

[go-nuts] Re: unexpected end of JSON input while unmarshal to struct

[Nathan Kerr]

I figured it out.

First off, the posted playground had a different json string and did not 
use your UnmarshalJSON function. These made translating between the 
non-working setup described in your post and the working playground 
annoying. In the future, share the non-working setup.

At the point when I figured things out, my code was: 
https://play.golang.org/p/aMvz_JTrjD. This won't run on playground because 
it uses github.com/pkg/errors to add context to the errors so I could see 
which error was returned along with a much needed stack trace.

I found two problems with the implementation of UnmarshalJSON:

1. tmp["response_data"] and tmp2["order"] return zero values when the key 
is not found. This happened, first, because of the difference between the 
posted json and the json in the posted playground. Second, because of the 
second problem.

2. json.Unmarshal uses a type's UnmarshalJSON function if it exists to do 
the unmarshalling. This created a loop where *LimitOrder.UnmarshalJSON 
calls json.Unmarshal, which calls *LimitOrder.UnmarshalJSON, and so on. 
Line 71 prints out the call stack for the returned error that confirms this.

My recommended way of doing things is https://play.golang.org/p/kRKevuX8LW, 
that is write out the structs you need. This will also allow you to check 
the status_code from the response. If your LimitOrder will outlive the 
response then change ResponseData.LimitOrder to be a pointer.

Hope this helps.

On Tuesday, February 21, 2017 at 6:25:10 AM UTC+1, Diogo Ribeiro wrote:
>
> Could you help me to understand why I'm always getting the error unexpected 
> end of JSON input while trying to unmarshal the following json to the 
> LimitOrder struct? It works if I use golang playground 
> https://play.golang.org/p/udPQ_TayXG but not locally running tests.
>
>
> P.S.: if I use map[string]json.RawMessage instead of LimitOrder struct 
> I'm able to execute the unmarshal.
>
>
> {
>   "response_data": {
> "order": {
>   "order_id": 3,
>   "coin_pair": "BRLBTC",
>   "order_type": 1,
>   "status": 4,
>   "has_fills": true,
>   "quantity": "1.",
>   "limit_price": "900.0",
>   "executed_quantity": "1.",
>   "executed_price_avg": "900.0",
>   "fee": "0.0030",
>   "created_timestamp": "1453835329",
>   "updated_timestamp": "1453835329",
>   "operations": [
> {
>   "operation_id": 1,
>   "quantity": "1.",
>   "price": "900.0",
>   "fee_rate": "0.30",
>   "executed_timestamp": "1453835329"
> }
>   ]
> }
>   },
>   "status_code": 100,
>   "server_unix_timestamp": "1453835329"}
>
> *LimitOrder struct*
>
>
> type LimitOrder struct {
>   OrderId int `json:"order_id"`
>   CoinPair string `json:"coin_pair"`
>   OrderType int `json:"order_type"`
>   Status int `json:"status"`
>   HasFills bool `json:"has_fills"`
>   Quantity float64 `json:"quantity,string"`
>   LimitPrice float64 `json:"limit_price,string"`
>   ExecutedQuantity float64 `json:"executed_quantity,string"`
>   ExecutedPriceAvg float64 `json:"executed_price_avg,string"`
>   Fee float64 `json:"fee,string"`
>   Operations []*Operation `json:"operations"`
>   CreatedTimestamp string `json:"created_timestamp"`
>   UpdatedTimestamp string `json:"updated_timestamp"`}
>
>
> and this is how I'm trying to unmarshal it
>
>
> func (limitOrder *LimitOrder) UnmarshalJSON(buf []byte) error {
>
>   tmp := make(map[string]json.RawMessage)
>   if err := json.Unmarshal(buf, &tmp); err != nil {
> return err
>   }
>
>   tmp2 := make(map[string]json.RawMessage)
>
>   if err := json.Unmarshal(tmp["response_data"], &tmp2); err != nil {
> return err
>   }
>
>   if err := json.Unmarshal(tmp2["order"], limitOrder); err != nil {
> return err
>   }
>
>   return nil}
>
>

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

[go-nuts] Re: Registering a Go app as a protocol handler under Mac OS X

[Nathan Kerr]

I managed to get this working.

https://gist.github.com/nathankerr/38d8b0d45590741b57f5f79be336f07c

I don't know what sort of app you are making, so I made a simple gui that 
displays the url received, with some filler text before any are. I think 
the non-ui parts should transfer to whatever you are doing.

A few notes:

- main.go lines 3-8 (cgo and import C) are important. They tell go how to 
build the c and obj-c parts.
- after C.StartURLHandler is called, HandlerURL will be called. HandleURL 
needs to be non-blocking as it seems to block the whole UI, so put 
long-running stuff in another go routine. I had to buffer labelText so the 
a url received at the same time the app starts will not hang the program.
- I had to put C.StartURLHandler before the ui.Main stuff so the first url 
would not be lost when the app is opened with `open myapp://whatever` and 
the app was not already running.
- running `make` will setup the app, including building it. You will need 
to `go get -u github.com/andlabs/ui` before doing so.
- You might need to change the url scheme to something else because you 
(presumably) already have an app that registers myapp. I didn't think of 
this earlier as I was trying to follow your question.
- Before trying to open the url, open the app itself. This will register 
the url scheme with macOS. After doing so, the app will work if it is 
already running or not.
- I was not able to get cmd-Q to close the app. Just click the close (red) 
button on the window. This seems to be a limit of the ui package.

This worked for me using go1.8 on macOS 10.12.3 and the latest version of 
the ui package.

Hope it helps you out.

Nathan

On Wednesday, July 6, 2016 at 11:50:02 PM UTC+2, chris...@gmail.com wrote:
>
> Hi,
>
> I'm trying to hook up a Go application to a URL protocol handler in Mac OS 
> X.  I want a user to be able to click on a link such as myapp://foo/bar and 
> have that launch myapp and be able to access the full query parameters. 
>  I've made it as far as getting the OS to register the handler and launch 
> the app.  That's done by bundling the Go binary into a OS X-style .app 
> package with a Info.plist file like this:  
> https://gist.github.com/chrissnell/db95a3c5ad6ceca4c673e96cca0f7548
>
> The challenge now is to figure out how to reference the query parameters 
> within Go.  I've determined that they're not passed as command-line 
> arguments.   From what I can tell, you have to use Cocoa libraries to get 
> at them  [1].  I don't know Objective-C or Swift, though, so that's where 
> I'm stumbling.
>
> There are cheap hacks to do this with AppleScript [2] but I wanted 
> something more native. 
>
> Has anybody done this?
>
> Chris
>
>
> [1] 
> http://fredandrandall.com/blog/2011/07/30/how-to-launch-your-macios-app-with-a-custom-url/
>
> [2] 
> https://support.shotgunsoftware.com/hc/en-us/community/posts/209485898-Launching-External-Applications-using-Custom-Protocols-under-OSX
>
>

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

Re: [go-nuts] Re: fmt: Why Golang doesn't have fmt.Printlnf?

[Nathan Fisher]

I would speculate it's a conscious tradeoff to keep the function count low
given it's an equivalent number of characters.
On Wed, 8 Feb 2017 at 03:32, 高橋誠二  wrote:

> yes, I know but other languages support it as default, isn't it?
>
> 2017年2月8日水曜日 12時31分00秒 UTC+9 dja...@gmail.com:
>
>
>
> On Wednesday, February 8, 2017 at 3:58:55 AM UTC+2, 高橋誠二 wrote:
>
> fmt package have no *lnf method, but in other langs,
> sometimes it implements Printlnf.
> Is there any reason?
>
>
> fmt.Printlnf(f,...) = fmt.Printf(f+"\n", ...)
> Djadala
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- from my thumbs to your eyes

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

[go-nuts] Re: Reading an .ini file

[Nathan Kerr]

Do you have a better suggestion?

On Tuesday, January 17, 2017 at 3:52:49 AM UTC+1, hui zhang wrote:
>
> this package is quit buggy 
> check its issues,   I list some , and still not fix yet
>
> 在 2017年1月15日星期日 UTC+8上午1:43:55，Nathan Kerr写道：
>>
>> Using a newer package might help.
>>
>> https://github.com/go-ini/ini looks to be under active development and 
>> is written by the author of https://github.com/Unknwon/goconfig, which 
>> also reads ini files but is now in bug fix only mode.
>>
>> Both claim to support comments.
>>
>>

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

[go-nuts] Reading an .ini file

[Nathan Kerr]

Using a newer package might help.

https://github.com/go-ini/ini looks to be under active development and is 
written by the author of https://github.com/Unknwon/goconfig, which also reads 
ini files but is now in bug fix only mode.

Both claim to support comments.

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

[go-nuts] Re: How to know the listener

[Nathan Kerr]

RemoteAddr was completely blank for me. This may be because I am running macOS.

The important part is that the different contents of RemoteAddr indicates that 
the request came from tcp or unix.

Dave Cheney's suggestion of skipping the auth for the unix listener is probably 
a better solution.

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

[go-nuts] Re: How to know the listener

[Nathan Kerr]

Hi,

You can use RemoteAddr from *http.Request to tell the difference. When the 
request comes through the unix socket, RemoteAddr is "" (i.e., blank).

The source for my test server is at https://play.golang.org/p/m3h_L_ACks

I used curl 127.0.0.1:3001 to test the tcp socket and curl-unix-socket 
unix://`pwd`/tmp_socket: from https://github.com/Soulou/curl-unix-socket to 
test the unix socket.

Hopefully my server is similar to what you had. If not, please post some 
code.

Cheers,

Nathan

On Tuesday, January 10, 2017 at 3:23:30 PM UTC+1, hawk hsieh wrote:
>
> I open a port 80 and a unix socket to listen http request simultaneously.
> I would like to determine where is the request coming from so that the 
> request from unix socket is no need to be authorized.
> Maybe the first problem is to know the listener from  http.ResponseWriter 
> or *http.Request. I guess.
> Is there any workaround or idiomatic manner to find the listener ? Any 
> idea?
>

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

[go-nuts] Documenting Interfaces

[Nathan Morley]

Hey all,

I have a brief question on the "best practices" for documenting Go code. I 
did a quick sweep through the official blog as well as the Effective Go 
article, but found no answer as of yet...

Let's say I have an interface like a database driver that gets implemented 
in multiple places. Which is better: to document just the interface itself, 
the interface and the clients that implement it, or just the clients?

I ask because if one were to have several implementations of a single 
interface, it quickly can become tiresome to copy/paste your comments 
around for the sake of consistency if you re-word something. I recognize 
that this may be one of those things best left up to the developer(s) at 
the time of development, and people may have several differing opinions on 
what is "best" here, but I'm curious.

Thanks in advance,

Morley

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

Re: [go-nuts] Re: type assertion: Can I DRY this up?

[Nathan Fisher]

I guess it becomes a question of what operations you want to do on the
data. If you look at the implementation of the Json package and sort
interface it might provide you with some approaches to achieve what you
want. Json demonstrates reflection, sort demonstrates how to invert the
problem in a way that works well with golang interfaces that doesn't
require generics.
On Tue, 1 Nov 2016 at 16:50, Bill Warner  wrote:

> Yes it's just a fragment. Let me clean it up a bit, then I'll share a
> playground link.
>
>
> On 11/1/16 12:47 PM, Volker Dobler wrote:
>
> Am Dienstag, 1. November 2016 02:07:49 UTC+1 schrieb wwa...@gmail.com:
>
> Hello all,
>
> I'm new to Go, and I have a question about identifying types as they're
> encountered in traversing a map[string]interface{}.
>
> I've ended up with a big sieve of type assertions something like this:
>
> if mt.Mi, ok = m.(map[string]int); ok {
> nval, ok = mt.Mi[mk]
> } else if mt.MI, ok = m.(map[string]interface{}); ok {
> nval, ok = mt.MI[mk]
> } else if mt.Mai, ok = m.(map[string][]int); ok {
> nval, ok = mt.Mai[mk]
> } else if mt.Mas, ok = m.(map[string][]string); ok {
> nval, ok = mt.Mas[mk]
> } else if mt.Mmm, ok = m.(map[string]map[string]interface{}); ok {
> nval, ok = mt.Mmm[mk]
>
> mt here is a struct that performs no work; it just associates a type to a
> name, so that the run-time can see the types of the left and the right
> sides of the assignment and determine if an assignment is possible. I
> really hate looking at that statement, but all my attempts at using
> reflection have failed as the compiler can't allocate with all the possible
> types that could be returned, even though in my application I only want to
> allocate for these five types. So that's my question: Can I DRY this up?
>
>
> The code you showed is basically a noop: If this is going to compile
> than nval must be of type interface {} and you could replace all this
> with a simple
> nval = m
> You either did not show the last else-block or something is strange here.
>
> V.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
- from my thumbs to yours

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

[go-nuts] fsnotify: maintainers wanted

[Nathan Youngman]

Hi,

Fsnotify provides notifications of changes to files and directories on BSD, 
Linux, Mac, and Windows. It is  imported by ~800 projects (via godoc.org).

While I would like to remain involved in fsnotify, I personally don't have 
enough cycles to handle all the incoming issues and pull requests coming 
into fsnotify.

It's a challenging project to work on, partially because it is 
cross-platform, trying to present a common API for operating system calls 
that are very different in behaviour. To address this, the best solution I 
can come up with is to split fsnotify into several platform-specific 
libraries. Each library would manage the low-level details of file system 
monitoring on that platform. With those libraries in place, the fsnotify 
library can then turn its focus to the higher level abstractions by 
depending on the low-level libraries.

Those low-level libraries could also offer more complete APIs when 
fsnotify's lowest common denominator solution is insufficient, as well as 
provide a foundation for alternatives to fsnotify.

This won't be possible without people stepping up to lead and maintain 
libraries for each platform. This is a call for help in making the fsnotify 
project better for gophers everywhere. It will involve low-level code, 
research, integration tests, documentation, helping investigate and address 
issues, code reviews, and more.

If you're interested, please get involved. The related GitHub issue is 
here: https://github.com/fsnotify/fsnotify/issues/183

Thanks,
Nathan.

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

[go-nuts] Re: How to setup go-swagger for an existing project to generate API docs

[Nathan Kerr]

I just tried this out and discovered that an operationId is required for 
swagger:route:

// swagger:route GET /profile getProfile


tags go between the path and the operationId:

// swagger:route GET /profile tag1 tag2 getProfile


Hope this helps.

On Monday, October 17, 2016 at 7:01:52 AM UTC+2, SakShak wrote:
>
> I have an existing project that needs a UI for the API. I want to use go 
> swagger but I am completely confused
> https://github.com/go-swagger/go-swagger/tree/master/examples/todo-list
>
> I want to set it up so I add annotations in the code and then run the 
> command swagger generate spec and it would generate the spec
>
> However whenever I run it, it prints 
> {"swagger":"2.0","paths":{},"definitions":{}}
>
> My project structure is as follows
>
> project/ 
>   main.go
>   api/
> router.go
>
> In main.go I have this annotation
>
> //go:generate swagger generate spec 
> package main
>
> In router above one of my handlers I have this annotation
>
> // swagger:route GET /profile
> //
> // Gets profile of user
> //
> // Produces:
> // - application/json
> // - application/x-protobuf
> //
> // Schemes: http, https, ws, wss
> //
> // Security:
> //   api_key:
> //   oauth: read, write
> //
> // Responses:
> //   default: genericError
> //   200: someResponse
> //   422: validationError
> r.GET("/profile", profileHandler
>
> I've been stuck trying to set up an api generator for a while. Any help is 
> much appreciated. If you have experience setting it up, please let me know 
> how you did it
>

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