[go-nuts] Re: Godoc / Local Project/ Documentation

[Rejoy]

Yes, this works and suffices my needs for now. So if I understand right, I 
should be creating just the single main package and import all other files 
as packages into the main package. Only then will the documentation show up 
for my local project as well.

On Monday, March 6, 2017 at 2:42:19 AM UTC+5:30, Rejoy wrote:
>
> In my local project folder (a web app) that has the go source files, I use 
> the go run command to get the output. Each of these files is called a 
> package main. I 'd like to create the documentation for the project. I run 
> godoc -http=:6060, but don't see any of the source files of my local 
> project. All I see is the list of subdirectories. 
> What would be the correct way to do the documentation of the local project 
> .
> 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] Re: Is it a concurrency issue?

[詹青朋]

Sorry for the misleading, these was a race condition, and I have found it.

It's not about reading / writing to the same map.

"this.Entries" is replaced by a new map in a timer, in another goroutine.

在 2017年3月3日星期五 UTC+8下午9:31:12，詹青朋写道：
>
> Hey guys,
>
> Here is my code, 
> https://github.com/myzhan/boomer/blob/dc6893a72c2b32c27ff6d7646a55b135493ba7e1/stats.go#L33
>
> I'm trying to figure out *why I got nil from "this.**Entries(a map)"*, 
> and I'm really confused.
>
> I hava checked if the key exists, and if not, I put a new key in 
> "this.Entries".
>
> If "clearAll" is called, "this.Entries" will be repalced by a new map.
>
> "init()" starts a goroutine to do all the things, get a entry from 
> "this.Entries" or call "clearAll". 
>
> Is it a concurrency issue?
>
> Thanks for your help.
>

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

[go-nuts] Re: How can I implement a TCP server using a model which similar to epoll (or kqueue, IOCP) rather than just using goroutine for each client?

[Nick Rio]

Thank you for reply.

No guys, it's me using too many memories, not Goroutine.

However, I believe if I can make those code in epoll-style, I can then 
build a task queue to handle those connections one by one in a queue when 
they back to active. For example, start one *accepter* goroutine + few 
*worker* goroutines. 

Then I could do buffer sharing within each *worker* instead of each 
connections. Which well reduce a huge bunch of memory requirement + also 
reduce numbers of goroutine.

-- 
You received this message because you are subscribed to the Google 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] Tool to detect unused parameters

[Ian Lance Taylor]

On Sun, Mar 5, 2017 at 9:34 AM, Daniel Martí  wrote:
>
> As a weekend project I've written a linter that detects unused
> parameters: https://github.com/mvdan/unparam
>
> As many of you may know, this is tricky business because of interfaces
> and build tags, among other things. So the tool isn't free from false
> positives, and I don't think it could be. But it does an okay job.
>
> Please try it out and share your thoughts. I've already sent a bunch of
> CLs to Go itself:
>
> https://go-review.googlesource.com/q/owner:mvdan%2540mvdan.cc+project:go+status:open

This is nice, thanks.

Ian

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

Re: [go-nuts] Godoc / Local Project/ Documentation

[Shawn Milochik]

You can append this to the URL:

?m=src

So this:

http://localhost:9000/pkg/myapp

becomes

http://localhost:9000/pkg/myapp/?m=src

From: https://godoc.org/golang.org/x/tools/cmd/godoc

You can still only see exported functions. If you pull out the code you
want to document into packages (other than "main") then they will be
documented normally. You're running into this problem because you're doing
something non-standard -- having a bunch of separate "main" applications in
a single folder. I don't know how/if the above will work on a folder with
multiple files containing "func main," though.

-- 
You received this message because you are subscribed to the Google 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] Slice from interface doesn't work as expected

[db047h]

This happens only because z is copied every time, but has nothing to do 
with interfaces. This exhibits the same behavior without 
interface{}: https://play.golang.org/p/C5KoUST4Zn

You could in fact modify the slice's existing content, but not the slice 
itself. For example:

x := make([]int, 1, 5) // we have 1 element
x[0] = 42
for i := 0; i < 4; i++ {

z := x

z[0] = z[0] + 1

z = append(z, i))

}

fmt.Println(x[0]) // would print 46
fmt.Println(len(x) // still 1


Well, unless you move z's declaration out of the loop as Jan suggested.

I'd recommend reading https://blog.golang.org/go-slices-usage-and-internals 
(manipulating slice values was not obvious to me until I read this).

Le jeudi 2 mars 2017 15:23:21 UTC+1, James Bardin a écrit :
>
> All assignments are a copy, so there's no way to modify a slice value that 
> is in an interface{}
>
> Just like if this were a function argument, you will need a pointer in 
> order to modify the value. 
> https://play.golang.org/p/kOdXUCiT_F
>
>
>
> On Thursday, March 2, 2017 at 9:01:48 AM UTC-5, Cornel Damian wrote:
>>
>> If you look where the slice is printed you will see that the data is 
>> missing. In the working example from me the data is there.
>> And even so, your example doesn't help me, what i've set there is just 
>> for example, i my code each time i add data to the slice i must first cast 
>> it.
>>
>> On Thursday, March 2, 2017 at 3:56:58 PM UTC+2, Jan Mercl wrote:
>>>
>>> On Thu, Mar 2, 2017 at 2:46 PM  wrote:
>>>
>>> > Can somebody explain me why? 
>>>
>>> Did you mean https://play.golang.org/p/GUVZBUQlEj ?
>>>
>>> -- 
>>>
>>> -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: How can I implement a TCP server using a model which similar to epoll (or kqueue, IOCP) rather than just using goroutine for each client?

[Manlio Perillo]

Il giorno domenica 5 marzo 2017 16:13:08 UTC+1, Nick Rio ha scritto:
>
> Greeting people,
>
> *TL;DR: The only option is to work with syscall package and build 
> everything ground up, or there are some easier way?*
>
> The story is, I'm working on a network related project (
> https://github.com/nickrio/coward) which been designed to take a lots of 
> connections. Most of those connections is just idle, but hey can back to 
> active at any time.
>
> Currently, that application is implemented in Go's style -- When a new 
> connection is accepted, a new goroutine is created, along with associated 
> buffer and structs.
>
> The downside of that is, I have to create a buffer for each goroutine (for 
> each connection), no matter that connection is active or not.
>

You would probably need to create a buffer for each connection even when 
using epoll.

And because of that, there will be a lots of memory space been wasted 
> (goroutine also cost few KB of memories).
>
>
Are you **really** sure that the additional memory required by the 
goroutines will be a problem for your application?
 

> So I'm thinking, if I can somehow re-implement connection handling in 
> epoll-like model, then I could save those idle memory for better memory 
> efficiency.
>
>
Idle connections will still need some memory: the memory you need to store 
for the per connection state.

> [...]

Manlio 

-- 
You received this message because you are subscribed to the Google 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] dh-golang usage

[kvs]

On Monday, March 6, 2017 at 12:13:44 AM UTC+3, Michael Stapelberg wrote:
>
>
>
> On Sun, Mar 5, 2017 at 9:14 PM,  wrote:
>
>> Hi!
>>
>> Michael, thank you very much for your reply! override_dh_auto_install 
>> feature does helped eliminate Go sources from the final .deb archive.
>>
>
> …why? Please describe what you did, what you expected, and what you see 
> instead.
>

Sorry, maybe wording in my replay wasn't quite correct, but everything 
worked as expected with override_dh_auto_install.
 

>  
>
>>
>> As for dh-golang not being for the end users -- do you know any 
>> alternatives which are more suited for the end users for building .deb 
>> packages?
>>
>
> I don’t, sorry.
>  
>
>>
>>
>> On Sunday, March 5, 2017 at 10:34:05 PM UTC+3, Michael Stapelberg wrote:
>>>
>>> dh-golang is not maintained by the Go team, so a better place to get 
>>> support is the pkg-go-maintainers mailing list.
>>>
>>> 1. No, and given dh-golang’s scope, this won’t be added (it’s a tool for 
>>> Debian development, not for end users).
>>> 2. No. Currently, we delete the source from binary-only packages, e.g. 
>>> in an override_dh_auto_install Makefile target. This might be changed in 
>>> the future.
>>>
>>> On Sun, Mar 5, 2017 at 3:36 PM,  wrote:
>>>
 Hello!

 I am trying to learn how to use debhelper infrastructure to build 
 Debian packages from Go code. I've install dh-golang and Go itself from 
 jessie-backports and all seems to work quite well. But I'd like to change 
 two things which don't fit well enough in my workflow.

 1. Is there a way to tell dh-golang to use different from the default 
 /usr installation prefix? I'd like to store everything under /opt 
 directory.
 2. Is there a way to tell dh-golang (or may be dh itself?) not to 
 include my Go source code into generated .deb package? I only want to 
 distribute compiled binaries and no source code.

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

>>>
>>>
>

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

Re: [go-nuts] dh-golang usage

[Michael Stapelberg]

On Sun, Mar 5, 2017 at 9:14 PM,  wrote:

> Hi!
>
> Michael, thank you very much for your reply! override_dh_auto_install
> feature does helped eliminate Go sources from the final .deb archive.
>

…why? Please describe what you did, what you expected, and what you see
instead.


>
> As for dh-golang not being for the end users -- do you know any
> alternatives which are more suited for the end users for building .deb
> packages?
>

I don’t, sorry.


>
>
> On Sunday, March 5, 2017 at 10:34:05 PM UTC+3, Michael Stapelberg wrote:
>>
>> dh-golang is not maintained by the Go team, so a better place to get
>> support is the pkg-go-maintainers mailing list.
>>
>> 1. No, and given dh-golang’s scope, this won’t be added (it’s a tool for
>> Debian development, not for end users).
>> 2. No. Currently, we delete the source from binary-only packages, e.g. in
>> an override_dh_auto_install Makefile target. This might be changed in the
>> future.
>>
>> On Sun, Mar 5, 2017 at 3:36 PM,  wrote:
>>
>>> Hello!
>>>
>>> I am trying to learn how to use debhelper infrastructure to build Debian
>>> packages from Go code. I've install dh-golang and Go itself from
>>> jessie-backports and all seems to work quite well. But I'd like to change
>>> two things which don't fit well enough in my workflow.
>>>
>>> 1. Is there a way to tell dh-golang to use different from the default
>>> /usr installation prefix? I'd like to store everything under /opt directory.
>>> 2. Is there a way to tell dh-golang (or may be dh itself?) not to
>>> include my Go source code into generated .deb package? I only want to
>>> distribute compiled binaries and no source code.
>>>
>>> --
>>> You received this message because you are subscribed 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] Godoc / Local Project/ Documentation

[Rejoy]

In my local project folder (a web app) that has the go source files, I use 
the go run command to get the output. Each of these files is called a 
package main. I 'd like to create the documentation for the project. I run 
godoc -http=:6060, but don't see any of the source files of my local 
project. All I see is the list of subdirectories. 
What would be the correct way to do the documentation of the local project .
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] dh-golang usage

[kvs]

Hi!

Michael, thank you very much for your reply! override_dh_auto_install 
feature does helped eliminate Go sources from the final .deb archive.

As for dh-golang not being for the end users -- do you know any 
alternatives which are more suited for the end users for building .deb 
packages?

On Sunday, March 5, 2017 at 10:34:05 PM UTC+3, Michael Stapelberg wrote:
>
> dh-golang is not maintained by the Go team, so a better place to get 
> support is the pkg-go-maintainers mailing list.
>
> 1. No, and given dh-golang’s scope, this won’t be added (it’s a tool for 
> Debian development, not for end users).
> 2. No. Currently, we delete the source from binary-only packages, e.g. in 
> an override_dh_auto_install Makefile target. This might be changed in the 
> future.
>
> On Sun, Mar 5, 2017 at 3:36 PM,  wrote:
>
>> Hello!
>>
>> I am trying to learn how to use debhelper infrastructure to build Debian 
>> packages from Go code. I've install dh-golang and Go itself from 
>> jessie-backports and all seems to work quite well. But I'd like to change 
>> two things which don't fit well enough in my workflow.
>>
>> 1. Is there a way to tell dh-golang to use different from the default 
>> /usr installation prefix? I'd like to store everything under /opt directory.
>> 2. Is there a way to tell dh-golang (or may be dh itself?) not to include 
>> my Go source code into generated .deb package? I only want to distribute 
>> compiled binaries and no source code.
>>
>> -- 
>> You received this message because you are subscribed 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: Bots on the mailing list

[Simon Ritchie]

> Apparently they're all "yahoo" email addresses.

Very few organisations supply free email addresses these days, pretty much 
only Google and Yahoo.  A few years ago the project I was working on needed 
a constant supply of new email addresses for testing.  They had to be real 
working email addresses.  I pretty quickly discovered that  to create a 
Google account and thus get a gmail address you have to give a working 
mobile phone number and you are only allowed ten accounts per phone 
number.  Yahoo on the other hand doesn't require any secondary contact 
information so you can create as many accounts as you like.  I ended up 
creating about 100 accounts to test my system..

So if somebody is pulling some sort of scam and needs to create a few 
thousand convincing-looking email addresses, Yahoo is their supplier of 
choice.

Having said that, my lawyer reminds me that I should not suggest for one 
moment that there is anything fishy about the addresses you mention.  I'm 
sure that whoever created them is pure as the driven snow.

Regards

Simon

>
>

-- 
You received this message because you are subscribed to the Google 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 on naming issue when interface vs main code struct

[mlg]

Henry,

thank you; your first paragraph was the answer I was looking for. Sorry for 
explaining so poorly. If I understand you correctly, you don't feel super 
strongly about it but you reckon you'd suffix "Impl" to the struct as a 
general rule. You'd leave it to the programmers discretion, though.

If possible, I'd appreciate if someone else would share a different opinion.

On Monday, 6 March 2017 04:35:13 UTC+13, Henry wrote:
>
> I would name your interface 'customer', the struct in the main code 
> 'customerImpl' and the struct in the test code 'mockedCustomer'.  However, 
> we are dealing with unexported types here. I tend to be less picky about 
> names for unexported types and prefer to leave them to each programmer's 
> discretion as long as the names are reasonable. 
>
> In general, I adopt the following guidelines:
>
> For an exported interface that does not represent any domain idea and they 
> are there because of their methods, I would adopt the "-er" naming 
> convention. (eg. Stringer, Closer, etc.)
> For an exported interface that represents a domain idea, I would use the 
> domain object name. It is preferable to have a noun with no adjective (eg. 
> Customer, Product, Shop, etc.)
>
> For a struct that is not exported but it is the concrete implementation 
> of an exported interface, I would use the "+Impl" 
> or "+Impl" to indicate that the struct is the 
> concrete implementation of a public interface (eg. customerImpl, 
> specialCustomerImpl, customShopImpl, etc.) .
>
> For a struct that is exported, I would use the "" format. 
> (eg. PublicAccountant, etc.).
>
> For any interface or struct that is used for testing purposes only, I 
> would prefix the name with the word "mocked".
>
> For any interface or struct that is not exported, I would leave them to 
> the programmer's discretion.
>
> That's what I would do. You may adopt a different naming convention. 
> As far as I know, Go puts very little restriction on the subject.
>
> On Sunday, March 5, 2017 at 10:04:47 AM UTC+7, mlg wrote:
>
>> Nope, that's not it :'(. Here's a better way to explain:
>>
>> main.go
>> // (unexported)
>> type database?? interface { // how do I name this?
>>   query() (result, error)
>> }
>>
>> // (unexported)
>> type database?? struct {} // how do I name this?
>>
>> func (d database??) query() (result, error) {
>>   ...
>> }
>>
>> test.go
>> // (unexported)
>> type mockDatabase struct {} // this name makes sense to me
>>
>> func (d database??) query() (result, error) {
>>   ...
>> }
>>
>> If I've known it was gonna be this hard to get my point across, I would 
>> have done this from the start; I'm terribly sorry for wasting so much of 
>> your time.
>>
>> On Sunday, 5 March 2017 15:30:17 UTC+13, Henry wrote:
>>>
>>> Let's see if I understand your question correctly. You have the 
>>> interface in your main code, and the implementing struct in your test code. 
>>> Do I get that right?
>>>
>>> Another question is whether the main code and the test code live in the 
>>> same package or different package. I normally put my test code in a 
>>> separate package. So if my main code is in package abc, then my test code 
>>> would be in abc_test.
>>>
>>

-- 
You received this message because you are subscribed to the Google 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] dh-golang usage

[Michael Stapelberg]

dh-golang is not maintained by the Go team, so a better place to get
support is the pkg-go-maintainers mailing list.

1. No, and given dh-golang’s scope, this won’t be added (it’s a tool for
Debian development, not for end users).
2. No. Currently, we delete the source from binary-only packages, e.g. in
an override_dh_auto_install Makefile target. This might be changed in the
future.

On Sun, Mar 5, 2017 at 3:36 PM,  wrote:

> Hello!
>
> I am trying to learn how to use debhelper infrastructure to build Debian
> packages from Go code. I've install dh-golang and Go itself from
> jessie-backports and all seems to work quite well. But I'd like to change
> two things which don't fit well enough in my workflow.
>
> 1. Is there a way to tell dh-golang to use different from the default /usr
> installation prefix? I'd like to store everything under /opt directory.
> 2. Is there a way to tell dh-golang (or may be dh itself?) not to include
> my Go source code into generated .deb package? I only want to distribute
> compiled binaries and no source code.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Golang Interview Areas

[Nyah Check]

Thanks Shawn

On Sun, Mar 5, 2017 at 7:50 PM, Shawn Milochik  wrote:

> I don't agree with the (admittedly assumed) premise that quizzing the
> interviewee with Go specifics is the best, or even a very good, way to go.
>
> I just stumbled upon this today and recommend it:
>
> http://kolesky.com/datums/job-search/
>
> I've also done a lot of interviewing and hiring. In my opinion,
> personality, culture fit, and curiosity/drive are the most important things
> (in no particular order). If they're smart and continue to learn on their
> own, I don't so much care how well they already know any one technology.
>
> Ask about projects they've worked on that weren't for school or work. Try
> to figure out if they're the kind of person who is passionate about what
> they do without actually asking directly (if they're not brain-dead they'll
> know the "right" answer).
>
> --
> You received this message because you are subscribed to the Google 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.
>



-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
You received this message because you are subscribed to the Google 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] Golang Interview Areas

[Shawn Milochik]

I don't agree with the (admittedly assumed) premise that quizzing the
interviewee with Go specifics is the best, or even a very good, way to go.

I just stumbled upon this today and recommend it:

http://kolesky.com/datums/job-search/

I've also done a lot of interviewing and hiring. In my opinion,
personality, culture fit, and curiosity/drive are the most important things
(in no particular order). If they're smart and continue to learn on their
own, I don't so much care how well they already know any one technology.

Ask about projects they've worked on that weren't for school or work. Try
to figure out if they're the kind of person who is passionate about what
they do without actually asking directly (if they're not brain-dead they'll
know the "right" answer).

-- 
You received this message because you are subscribed to the Google 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] sqlEZ: the easiest way to use a SQL database

[jmacwhyte]

Thanks Konstantin,

This is the kind of feedback I was looking for! I forgot to include the 
link to my github repo in my original post (did you find it anyway?) so I'm 
not sure if you read my README. I took a look at sqlx before writing sqlez, 
and while sqlx is a great improvement over the basic sql package, I thought 
it could be simplified even further and decided to write sqlez. The goal I 
had was to allow the user to just pass structs back and forth, without any 
need for further preparation before passing those structs to/from other 
parts of their program. I couldn't think of a succinct way to explain that, 
which is why I chose to include a lot of code examples.

I will re-write my README with what you said in mind (remove the 
"marketing", which was supposed to be mostly a joke anyway :), and explain 
how it relates to other options). Here's the repo just in 
case: https://github.com/jmacwhyte/sqlez

On Sunday, March 5, 2017 at 6:10:26 AM UTC-8, Konstantin Khomoutov wrote:
>
> On Sun, 5 Mar 2017 12:42:24 +0200 
> Janne Snabb  wrote: 
>
> > > After seeing a need for simplifying SQL databases in Go, I have 
> > > written a new package that makes it very easy to do basic SELECT, 
> > > INSERT, and UPDATE database operations. Essentially you define a 
> > > struct that corresponds with the data in your database, and then 
> > > you can simply pass that struct to my package to insert and 
> > > retrieve data. I'm now using it in one of my projects, and it has 
> > > reduced database-related code by 60%, making things much more 
> > > readable! 
> > Looks similar to https://github.com/jmoiron/sqlx which is well 
> > established. Might be a good idea to add a short summary of 
> > differences/additional benefits compared to sqlx in README. 
>
> I concur.  [1] has a pretty incomplete (a popular package sqlx is 
> missing) but a sizeable list of ORM projects, and [2] yields lots of 
> stuff, too. 
>
> Go is a natural pick for a certain kind of projects.  One of these 
> kinds is a "typical webapp"; since webapps require state persistence, 
> they need databases, and this leads to Go enjoing true proliferation 
> of "web frameworks" and "SQL ORMs". 
>
> What I'm leading to is that while it's nice to see your excitement 
> about Go and stuff you can do with it, I'm afraid it's hard to make 
> anyone who use Go for some time immediately excited with a piece of 
> news about a new web framework or an SQL ORM. ;-) 
>
> So instead of marketing propaganda, it would be cool to see comparisons 
> with the so-called "prior works".  That would surely be less shiny but 
> would indicate that you have actually researched what's already there, 
> identified the weak spots, and fixed at least some of the shortcomings 
> of the existing packages. 
>
> To explain all that from another PoV, consider the following. 
> While competition is a great thing, it tends to produce lots of 
> half-backed (and then usually abandoned by their sole authors) stuff. 
> So, say, we use sqlx in two our $dayjob projects.  I reserve that sqlEZ 
> might indeed be better in some areas but the statement "he easiest way 
> to use a SQL database" is not a convincing statement for us to 
> consider switching or even spending time researching -- simply because 
> it's marketing, and thanks to omnipresent commercials, those of us who 
> wasn't living on a deserted rock for the last couple of decades learned 
> not to trust slogans blindly ;-)  We'd like to see hard facts instead. 
> Hope you'll understand. 
>
> 1. https://github.com/golang/go/wiki/Projects#orm 
> 2. https://godoc.org/?q=sql 
>

-- 
You received this message because you are subscribed to the Google 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: sqlEZ: the easiest way to use a SQL database

[jmacwhyte]

This is my first post to this mailing list, and wouldn't you know it, I 
totally forgot to include the link to the repo. Talk about a bad first 
impression! Here it is: https://github.com/jmacwhyte/sqlez

On Saturday, March 4, 2017 at 9:25:29 PM UTC-8, jmacwhyte wrote:
>
> Hello all,
>
> After seeing a need for simplifying SQL databases in Go, I have written a 
> new package that makes it very easy to do basic SELECT, INSERT, and UPDATE 
> database operations. Essentially you define a struct that corresponds with 
> the data in your database, and then you can simply pass that struct to my 
> package to insert and retrieve data. I'm now using it in one of my 
> projects, and it has reduced database-related code by 60%, making things 
> much more readable!
>
> Here's how easy it is to retrieve some info, make some changes, and return 
> it to the database:
>
> type SumoWreslter struct {
>  Name string `db:"name"`
>  Age int `db:"age"`
>  Rank string `db:"level"`
> }
>
> func main() {
>  db, err := sqlez.Open("databaseDriver", "dataSource")
>
>  tooOld := 30
>
>  results, err := db.SelectFrom("wrestlers", SumoWreslter{}, sqlez.Params{
>Where: `age < ? AND level = "master"`,
>OrderBy: `age DESC`,
>Limit: 1,
>  }, tooOld)
>
>  theOne := results[0].(SumoWreslter)
>  theOne.Rank = "grand master"
>  // Manipulate data further
>
>  _, err := db.Update("wrestlers", theOne, sqlez.Params{
>Where: `name = ?`,
>}, theOne.Name)
> }
>
> // Done!
>
> I think it's a very handy tool, especially for getting started quickly. It 
> can handle embedded structs, it can store and retrieve Go datatypes like 
> structs and maps using JSON, and uses sql.NullString under the hood to 
> avoid errors when trying to pull TEXT columns that are NILL.
>
> I would love any feedback or suggestions, both on the code and the 
> documentation I've written (which is geared more for people who are new-ish 
> to Go).
>
> Thanks!
> James
>

-- 
You received this message because you are subscribed to the Google 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] Golang Interview Areas

[Nyah Check]

Is that so? :-)

On Sun, Mar 5, 2017 at 6:51 PM, andrey mirtchovski 
wrote:

> the first question i usually ask is "what's the name of the gopher" :)
>
> On Sun, Mar 5, 2017 at 10:50 AM, Nyah Check  wrote:
> > Hi Gophers,
> >
> > I am an entry SE and I'm to interview someone to join our Golang Backend
> > team. I've told them I'm not experienced enough and they refused. Can
> anyone
> > please guide me on what to probe in any Golang Developer during the
> > interview?
> >
> > Thanks,
> > Nyah
> >
> > --
> > "The heaviest penalty for declining to rule is to be ruled by someone
> > inferior to yourself." --Plato
> >
> > --
> > You received this message because you are subscribed to the Google 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.
>



-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

-- 
You received this message because you are subscribed to the Google 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] Docs - German translations updated

[HaWe]

The following translations have been updated to match Go 1.8:

http://www.bitloeffel.de/DOC/golang/install_de.html
http://www.bitloeffel.de/DOC/golang/install-source_de.html
http://www.bitloeffel.de/DOC/golang/code_de.html
http://www.bitloeffel.de/DOC/golang/effective_go_de.html
http://www.bitloeffel.de/DOC/golang/go_spec_de.html
http://www.bitloeffel.de/DOC/golang/go_faq_de.html

Hope it helps some.

-- 
You received this message because you are subscribed to the Google 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] Golang Interview Areas

[andrey mirtchovski]

the first question i usually ask is "what's the name of the gopher" :)

On Sun, Mar 5, 2017 at 10:50 AM, Nyah Check  wrote:
> Hi Gophers,
>
> I am an entry SE and I'm to interview someone to join our Golang Backend
> team. I've told them I'm not experienced enough and they refused. Can anyone
> please guide me on what to probe in any Golang Developer during the
> interview?
>
> Thanks,
> Nyah
>
> --
> "The heaviest penalty for declining to rule is to be ruled by someone
> inferior to yourself." --Plato
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Golang Interview Areas

[Nyah Check]

Hi Gophers,

I am an entry SE and I'm to interview someone to join our Golang Backend
team. I've told them I'm not experienced enough and they refused. Can
anyone please guide me on what to probe in any Golang Developer during the
interview?

Thanks,
Nyah

-- 
"The heaviest penalty for declining to rule is to be ruled by someone
inferior to yourself." --*Plato*

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

[go-nuts] How can I implement a TCP server using a model which similar to epoll (or kqueue, IOCP) rather than just using goroutine for each client?

[Tamás Gulácsi]

Are you sure that those goroutines will consume too much memory?
As the Go runtime implements a very sophisticated network stack on top of 
epoll, I wouldn't start from scratch, but use it, eliminating unneeded 
allocations (buffers).

-- 
You received this message because you are subscribed to the Google 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] Tool to detect unused parameters

[Daniel Martí]

Hey all,

As a weekend project I've written a linter that detects unused
parameters: https://github.com/mvdan/unparam

As many of you may know, this is tricky business because of interfaces
and build tags, among other things. So the tool isn't free from false
positives, and I don't think it could be. But it does an okay job.

Please try it out and share your thoughts. I've already sent a bunch of
CLs to Go itself:

https://go-review.googlesource.com/q/owner:mvdan%2540mvdan.cc+project:go+status:open

-- 
Daniel Martí - mv...@mvdan.cc - https://mvdan.cc/

-- 
You received this message because you are subscribed to the Google 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 on naming issue when interface vs main code struct

[Henry]

I would name your interface 'customer', the struct in the main code 
'customerImpl' and the struct in the test code 'mockedCustomer'.  However, 
we are dealing with unexported types here. I tend to be less picky about 
names for unexported types and prefer to leave them to each programmer's 
discretion as long as the names are reasonable. 

In general, I adopt the following guidelines:

For an exported interface that does not represent any domain idea and they 
are there because of their methods, I would adopt the "-er" naming 
convention. (eg. Stringer, Closer, etc.)
For an exported interface that represents a domain idea, I would use the 
domain object name. It is preferable to have a noun with no adjective (eg. 
Customer, Product, Shop, etc.)

For a struct that is not exported but it is the concrete implementation 
of an exported interface, I would use the "+Impl" 
or "+Impl" to indicate that the struct is the 
concrete implementation of a public interface (eg. customerImpl, 
specialCustomerImpl, customShopImpl, etc.) .

For a struct that is exported, I would use the "" format. 
(eg. PublicAccountant, etc.).

For any interface or struct that is used for testing purposes only, I 
would prefix the name with the word "mocked".

For any interface or struct that is not exported, I would leave them to the 
programmer's discretion.

That's what I would do. You may adopt a different naming convention. As far 
as I know, Go puts very little restriction on the subject.

On Sunday, March 5, 2017 at 10:04:47 AM UTC+7, mlg wrote:

> Nope, that's not it :'(. Here's a better way to explain:
>
> main.go
> // (unexported)
> type database?? interface { // how do I name this?
>   query() (result, error)
> }
>
> // (unexported)
> type database?? struct {} // how do I name this?
>
> func (d database??) query() (result, error) {
>   ...
> }
>
> test.go
> // (unexported)
> type mockDatabase struct {} // this name makes sense to me
>
> func (d database??) query() (result, error) {
>   ...
> }
>
> If I've known it was gonna be this hard to get my point across, I would 
> have done this from the start; I'm terribly sorry for wasting so much of 
> your time.
>
> On Sunday, 5 March 2017 15:30:17 UTC+13, Henry wrote:
>>
>> Let's see if I understand your question correctly. You have the interface 
>> in your main code, and the implementing struct in your test code. Do I get 
>> that right?
>>
>> Another question is whether the main code and the test code live in the 
>> same package or different package. I normally put my test code in a 
>> separate package. So if my main code is in package abc, then my test code 
>> would be in abc_test.
>>
>

-- 
You received this message because you are subscribed to the Google 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] dh-golang usage

[kvs]

Hello!

I am trying to learn how to use debhelper infrastructure to build Debian 
packages from Go code. I've install dh-golang and Go itself from 
jessie-backports and all seems to work quite well. But I'd like to change 
two things which don't fit well enough in my workflow.

1. Is there a way to tell dh-golang to use different from the default /usr 
installation prefix? I'd like to store everything under /opt directory.
2. Is there a way to tell dh-golang (or may be dh itself?) not to include 
my Go source code into generated .deb package? I only want to distribute 
compiled binaries and no source code.

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

[go-nuts] How can I implement a TCP server using a model which similar to epoll (or kqueue, IOCP) rather than just using goroutine for each client?

[nickriose]

Greeting people,

*TL;DR: The only option is to work with syscall package and build 
everything ground up, or there are some easier way?*

The story is, I'm working on a network related project 
(https://github.com/nickrio/coward) which been designed to take a lots of 
connections. Most of those connections is just idle, but hey can back to 
active at any time.

Currently, that application is implemented in Go's style -- When a new 
connection is accepted, a new goroutine is created, along with associated 
buffer and structs.

The downside of that is, I have to create a buffer for each goroutine (for 
each connection), no matter that connection is active or not. And because 
of that, there will be a lots of memory space been wasted (goroutine also 
cost few KB of memories).

So I'm thinking, if I can somehow re-implement connection handling in 
epoll-like model, then I could save those idle memory for better memory 
efficiency.

After dug few pages of source code on golang.org, I discover that in order 
to do so, I have to work with some *low* level system calls (the package 
name is literally syscall) and runtime package.

So before I get started, I want to do the last check to make sure there are 
no any other way to go (No built-in package or x package will help me to do 
that. Sorry, I'm new to Golang, if there are a magic hidden inside, I 
probably wouldn't found it. So better ask to make sure), so I don't waste 
my time doing it.

Thank you!

(Sorry for my English)

-- 
You received this message because you are subscribed to the Google 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] sqlEZ: the easiest way to use a SQL database

[Tong Sun]

Totally agree. 

On Sunday, March 5, 2017 at 9:10:26 AM UTC-5, Konstantin Khomoutov wrote:
>
> On Sun, 5 Mar 2017 12:42:24 +0200 
> Janne Snabb  wrote: 
>
> > > After seeing a need for simplifying SQL databases in Go, I have 
> > > written a new package that makes it very easy to do basic SELECT, 
> > > INSERT, and UPDATE database operations. Essentially you define a 
> > > struct that corresponds with the data in your database, and then 
> > > you can simply pass that struct to my package to insert and 
> > > retrieve data. I'm now using it in one of my projects, and it has 
> > > reduced database-related code by 60%, making things much more 
> > > readable! 
> > Looks similar to https://github.com/jmoiron/sqlx which is well 
> > established. Might be a good idea to add a short summary of 
> > differences/additional benefits compared to sqlx in README. 
>

Here is another one claimed to be the easiest way to code a SQL database 
program, even from the design phase:

 https://github.com/goadesign/

I concur.  [1] has a pretty incomplete (a popular package sqlx is 
> missing) but a sizeable list of ORM projects, and [2] yields lots of 
> stuff, too. 
>
> Go is a natural pick for a certain kind of projects.  One of these 
> kinds is a "typical webapp"; since webapps require state persistence, 
> they need databases, and this leads to Go enjoing true proliferation 
> of "web frameworks" and "SQL ORMs". 
>
> What I'm leading to is that while it's nice to see your excitement 
> about Go and stuff you can do with it, I'm afraid it's hard to make 
> anyone who use Go for some time immediately excited with a piece of 
> news about a new web framework or an SQL ORM. ;-) 
>
> So instead of marketing propaganda, it would be cool to see comparisons 
> with the so-called "prior works".  That would surely be less shiny but 
> would indicate that you have actually researched what's already there, 
> identified the weak spots, and fixed at least some of the shortcomings 
> of the existing packages. 
>
> To explain all that from another PoV, consider the following. 
> While competition is a great thing, it tends to produce lots of 
> half-backed (and then usually abandoned by their sole authors) stuff. 
> So, say, we use sqlx in two our $dayjob projects.  I reserve that sqlEZ 
> might indeed be better in some areas but the statement "he easiest way 
> to use a SQL database" is not a convincing statement for us to 
> consider switching or even spending time researching -- simply because 
> it's marketing, and thanks to omnipresent commercials, those of us who 
> wasn't living on a deserted rock for the last couple of decades learned 
> not to trust slogans blindly ;-)  We'd like to see hard facts instead. 
> Hope you'll understand. 
>
> 1. https://github.com/golang/go/wiki/Projects#orm 
> 2. https://godoc.org/?q=sql 
>

-- 
You received this message because you are subscribed to the Google 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] sqlEZ: the easiest way to use a SQL database

[Konstantin Khomoutov]

On Sun, 5 Mar 2017 12:42:24 +0200
Janne Snabb  wrote:

> > After seeing a need for simplifying SQL databases in Go, I have
> > written a new package that makes it very easy to do basic SELECT,
> > INSERT, and UPDATE database operations. Essentially you define a
> > struct that corresponds with the data in your database, and then
> > you can simply pass that struct to my package to insert and
> > retrieve data. I'm now using it in one of my projects, and it has
> > reduced database-related code by 60%, making things much more
> > readable!
> Looks similar to https://github.com/jmoiron/sqlx which is well
> established. Might be a good idea to add a short summary of
> differences/additional benefits compared to sqlx in README.

I concur.  [1] has a pretty incomplete (a popular package sqlx is
missing) but a sizeable list of ORM projects, and [2] yields lots of
stuff, too.

Go is a natural pick for a certain kind of projects.  One of these
kinds is a "typical webapp"; since webapps require state persistence,
they need databases, and this leads to Go enjoing true proliferation
of "web frameworks" and "SQL ORMs".

What I'm leading to is that while it's nice to see your excitement
about Go and stuff you can do with it, I'm afraid it's hard to make
anyone who use Go for some time immediately excited with a piece of
news about a new web framework or an SQL ORM. ;-)

So instead of marketing propaganda, it would be cool to see comparisons
with the so-called "prior works".  That would surely be less shiny but
would indicate that you have actually researched what's already there,
identified the weak spots, and fixed at least some of the shortcomings
of the existing packages.

To explain all that from another PoV, consider the following.
While competition is a great thing, it tends to produce lots of
half-backed (and then usually abandoned by their sole authors) stuff.
So, say, we use sqlx in two our $dayjob projects.  I reserve that sqlEZ
might indeed be better in some areas but the statement "he easiest way
to use a SQL database" is not a convincing statement for us to
consider switching or even spending time researching -- simply because
it's marketing, and thanks to omnipresent commercials, those of us who
wasn't living on a deserted rock for the last couple of decades learned
not to trust slogans blindly ;-)  We'd like to see hard facts instead.
Hope you'll understand.

1. https://github.com/golang/go/wiki/Projects#orm
2. https://godoc.org/?q=sql

-- 
You received this message because you are subscribed to the Google 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] Dumbest golang mistakes

[Tom]

What are the dumbest, most obvious ways you have shot yourself in the foot?


I just spend 3 hours debugging a network issue across three servers in dev, 
after copy-pasting some code from a crappy proof-of-concept into a 
complicated package with lots of modules.

defer serverConn.Close()

1 line. 3. hours.
Welp.



-- 
You received this message because you are subscribed to the Google 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] sqlEZ: the easiest way to use a SQL database

[Janne Snabb]

Looks similar to https://github.com/jmoiron/sqlx which is well
established. Might be a good idea to add a short summary of
differences/additional benefits compared to sqlx in README.

Janne Snabb
sn...@epipe.com

On 2017-03-05 01:36, jmacwhyte wrote:
> Hello all,
> 
> After seeing a need for simplifying SQL databases in Go, I have written
> a new package that makes it very easy to do basic SELECT, INSERT, and
> UPDATE database operations. Essentially you define a struct that
> corresponds with the data in your database, and then you can simply pass
> that struct to my package to insert and retrieve data. I'm now using it
> in one of my projects, and it has reduced database-related code by 60%,
> making things much more readable!
> 
> Here's how easy it is to retrieve some info, make some changes, and
> return it to the database:
> 
> |
> type SumoWreslterstruct{
>  Namestring`db:"name"`
>  Ageint`db:"age"`
>  Rankstring`db:"level"`
> }
> 
> func main(){
>  db,err :=sqlez.Open("databaseDriver","dataSource")
> 
>  tooOld :=30
> 
>  results,err :=db.SelectFrom("wrestlers",SumoWreslter{},sqlez.Params{
>Where:`age < ? AND level = "master"`,
>OrderBy:`age DESC`,
>Limit:1,
>  },tooOld)
> 
>  theOne :=results[0].(SumoWreslter)
>  theOne.Rank="grand master"
>  // Manipulate data further
> 
>  _,err :=db.Update("wrestlers",theOne,sqlez.Params{
>Where:`name = ?`,
>},theOne.Name)
> }
> 
> // Done!
> |
> 
> I think it's a very handy tool, especially for getting started quickly.
> It can handle embedded structs, it can store and retrieve Go datatypes
> like structs and maps using JSON, and uses sql.NullString under the hood
> to avoid errors when trying to pull TEXT columns that are NILL.
> 
> I would love any feedback or suggestions, both on the code and the
> documentation I've written (which is geared more for people who are
> new-ish to Go).
> 
> Thanks!
> James
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Re: How Build New Golang Console App in a Main Go App?

[Florin Pățan]

You can make an auto-run generator without needing to compile an 
application. Create a custom DSL and have that distributed with a binary 
that can read it and behave accordingly.

But if you do need that, for whatever reason, say allow more complex 
scenarios / higher degree of customization, then you can make installing Go 
a requirement or you can redistribute Go (as per what the Go license allows 
you). After that use it from within the application in a custom manner by 
creating the command as a proxy to the Go binary along with any other 
params needed for your app to generate the binary.


Hope it helps.


P.S. Don't !!! if you want replies, I hardly think that less than 24 hours 
reply time warrants this and is extremely rude.

On Saturday, March 4, 2017 at 3:00:13 PM UTC, erfang...@gmail.com wrote:
>
> i want make a autorun generator , mean this make a string code and next 
> build output file(as golang).
>
> how can 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] How select mysql with Bind Param Using go

[erfangnulinux]

Hello,
i want execute example `select * from  where id=?` with bind 
param(s) and get `all rows`.
https://github.com/go-sql-driver/mysql/wiki/Examples

```
db, err := sql.Open("mysql", "user:password@/dbname")
if err != nil {
panic(err.Error())  // Just for example purpose. You should use 
proper error handling instead of panic
}
defer db.Close()
// Execute the query
rows, err := db.Query("SELECT * FROM table")
if err != nil {
panic(err.Error()) // proper error handling instead of panic in 
your app
}
// Get column names
columns, err := rows.Columns()
if err != nil {
panic(err.Error()) // proper error handling instead of panic in 
your app
}
// Make a slice for the values
values := make([]sql.RawBytes, len(columns))
// rows.Scan wants '[]interface{}' as an argument, so we must copy the
// references into such a slice
// See http://code.google.com/p/go-wiki/wiki/InterfaceSlice for details
scanArgs := make([]interface{}, len(values))
for i := range values {
scanArgs[i] = [i]
}
// Fetch rows
for rows.Next() {
// get RawBytes from data
err = rows.Scan(scanArgs...)
if err != nil {
panic(err.Error()) // proper error handling instead of panic in 
your app
}
// Now do something with the data.
// Here we just print each column as a string.
var value string
for i, col := range values {
// Here we can check if the value is nil (NULL value)
if col == nil {
value = "NULL"
} else {
value = string(col)
}
fmt.Println(columns[i], ": ", value)
}
fmt.Println("---")
}
if err = rows.Err(); err != nil {
panic(err.Error()) // proper error handling instead of panic in 
your app
}
```
i want add bind param of `?` to this source.
may help me?


https://github.com/go-sql-driver/mysql/issues/548

-- 
You received this message because you are subscribed to the Google 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 Build New Golang Console App in a Main Go App?

[erfangnulinux]

On Saturday, March 4, 2017 at 6:30:13 PM UTC+3:30, erfang...@gmail.com 
wrote:
>
> i want make a autorun generator , mean this make a string code and next 
> build output file(as golang).
>
> how can 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.