Minor follow up along those lines: i think we *could* add a new keyword or
form (for any purpose), it just needs to be one that does not break
existing programs.
as an example
x := 12345.12345
a := int(x)
could be elaborated as
x := 12345.12345 rounded 27 //bits of mantissa
or
a := int(x,
You'll need to handle it yourself. Gzipped requests (unlike responses) are
somewhat nonstandard.
(With a response, the client can say it supports gzip, but with requests,
you basically have to prenegotiate it out-of-band -- at least, that's how
I've encountered it in the past.)
On Mar 4, 2017
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
On linux, you can read in /proc/stat for cpu specific and aggregated data.
Other info in /proc/stat can get you info on each running process. Google
for procfs and /proc/stat...
On Tuesday, September 25, 2012 at 11:05:12 AM UTC-4, ISockGo wrote:
>
> Hi,
>
> I am almost done with a chat
Hello again,
Of course it's my very first post to this group and I forget to include the
link to my project! If it's possible to edit my original message, I will.
Here is the link:
sqlEZ
https://github.com/jmacwhyte/sqlez
--
You received this message because you are subscribed to the Google
I'm not aware of a Go convention for this purpose.
If the struct is private to the package you can use a plain "customer". If
not you can use something like "BasicCustomer", "SimpleCustomer" or
"GenericCustomer". I rather leave the interface name as "Customer" instead
of using something like
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
//
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
Henry,
the case that I'm describing is when you're not exporting any and you're
using your interface for mocking purposes. The interface cannot be called
MockedCustomer, because it's used in the main code...there will be a
mockCustomer struct in the test that implements the interface. The
If you are exporting your interface but hiding your implementation, I usually
name my interface Customer and my struct customerImpl. If you are using your
interface for mocking purposes only, I would name it MockedCustomer. If you're
exporting both the interface and its implementations, I would
If you are exporting your interface but hiding your implementation, I usually
name my interface Customer and my struct customerImpl. If you are using your
interface for mocking purposes only, I would name it MockedCustomer. If you're
exporting both the interface and its implementations, I would
Run `type go` to see if `go` is an alias or function that is executing the
go binary with GOPATH set.
On Saturday, March 4, 2017 at 3:25:34 PM UTC-8, Bruno Albuquerque wrote:
>
> Something appears to be broken:
>
> $ echo $GOPATH
> /home/bga/go-dev
>
> $ echo $GOBIN
> /home/bga/go-dev/bin
>
> $
>> AFAIK, there is (still?) no out-of-the-box support for gzip.
I believe this is the answer. I figured I'd fish around to see if anyone
had already solved and open sourced a solution to this problem.
>> See, for example, https://github.com/NYTimes/gziphandler
While certainly related, this
Lars,
100% agree with your rationale; my question is an edge case of it.
The only need for these interfaces is for mocking the struct on tests (as
shown in the link on my original post). Therefore, there is no other
implementation of the interface.
Your suggestion is close to our discussed
On Sat, Mar 04, 2017 at 03:57:48PM -0800, mlg wrote:
> according to your rationale, I believe the case I'm referring to is when
> the interface represents a domain object (e.g. Consumer). In such case, if
> you don't plan on exporting your interface (therefore naming it
> `consumer`), how would
Henry,
according to your rationale, I believe the case I'm referring to is when
the interface represents a domain object (e.g. Consumer). In such case, if
you don't plan on exporting your interface (therefore naming it
`consumer`), how would you name the implementing struct and why? If
Something appears to be broken:
$ echo $GOPATH
/home/bga/go-dev
$ echo $GOBIN
/home/bga/go-dev/bin
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/bga/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
Looks really good, thanks.
Is it possible to support the codeship.com badges? They are ID based. e.g.,
https://codeship.com/projects/147070
https://codeship.com/projects/135255
BTW, just to clearly understand the command line:
emd gen -out README.md
> to generate an updated version of the
AFAIK, there is (still?) no out-of-the-box support for gzip.
See, for example, https://github.com/NYTimes/gziphandler
- johnk
> On Mar 4, 2017, at 5:11 PM, Kevin Conway wrote:
>
> I'm running a go 1.7 HTTP server. One of my clients is applying gzip to the
> POST
I'm running a go 1.7 HTTP server. One of my clients is applying gzip to the
POST body of their request and applying the appropriate content-encoding
header. The current server implementation in go, unlike the client, does
not appear to automatically handle decompression of the body. This is
which golang jsonpath library do you recommend?
https://golanglibs.com/top?q=JSONpath
shows a bunch of them almost with identical purpose.
- which one do you recommend?
- which one is most kosher to http://goessner.net/articles/JsonPath/?
Thanks
--
You received this message because you are
There would be a way to add them without adding a new keyword:
{
// stuff
} for condition
I'm not saying I want it, or that it's a good idea, just that "we can't add
a new keyword" doesn't seem a good argument for not doing it. At least at a
cursory glance I don't see why we'd need the do
How Insert with Bind param from Array to Mysql Using Go?
==> stmt.Exec()
this func get all value just one time, but i want set value in for(one and
one).
var values=args[1]
var sql_first string="INSERT INTO "+table+" "
var sql_end string=" VALUES("
var sql_field string=""
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
On Saturday, March 4, 2017 at 12:56:23 AM UTC+8, James Bardin wrote:
>
>
>
> On Friday, March 3, 2017 at 11:47:10 AM UTC-5, T L wrote:
>>
>>
>> Yes, the suggestion needs more allocations in creating new string and
>> slice values.
>> But it makes copying string and slice values a little faster
I believe there are two kinds of interface: one that represents a domain object
(eg. Consumer) and the other that represents a one or two methods (eg.
Stringer, ReadCloser). Typically, you use the first one when you use interface
to represent a data type. The second one is used when you need
You cannot build a Go application without the Go compiler. You can try to find
a way to bundle it in your application but that would be very complex.
If you'd liked to describe why do you need this functionality maybe a different
solution can be found.
--
You received this message because you
27 matches
Mail list logo