Re: [go-nuts] sql.Row doubt
FWIW, things like `SELECT * FROM ...` are in my opinion a code smell:
there are usually some (implicit) expectations on which columns will be
returned in what order that'll break horribly if someone two departments
removed decides "this table needs another column".
In my experience, it's almost always better to explicitly encode queries
(or build them with a query builder) than to build them manually at run
time.
On 14.08.21 15:43, Daniel da Silva wrote:
I know my resultset will only have one row. But I don't know about
columns. e.g.
func GetData(db *sql.DB, ent Entity, tableName, uniqueField string, value
interface{}) error {
query := fmt.Sprintf("SELECT * FROM %s WHERE %s = $1", tableName,
uniqueField)
row := db.QueryRow(query, value)
columns := []string{} // columns, err := row.Columns()
if err := row.Scan(ent.Pointers(columns)...); err != nil {
return err
}
return nil
}
On Saturday, August 14, 2021 at 5:08:12 AM UTC-3 Tamás Gulácsi wrote:
It could, but what for? sql.Row is already a convenience wrapper
for I-know-I-want-only-one-row,
so you know what kind of data are you retrieving, but you know
it's only one row?
daniel...@omie.com.br a következőt írta (2021. augusztus 13.,
péntek, 19:04:24 UTC+2):
Yes i ever use Query() instead of QueryRow().
My doubt is more about the API design.
If exists *sql.Row with Scan() method why not implements
Columns() ?
On Thursday, August 5, 2021 at 3:43:44 PM UTC-3
eli...@gmail.com wrote:
In what case do you find the need to call Columns() on a
Row? Generally if you have access to a Row, you also have
access to a Rows, which does have a Columns() method.
Eli
On Thu, Aug 5, 2021 at 10:34 AM Daniel da Silva
wrote:
Hello guys!
Why doesn't sql.Row implement the Columns() method?
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...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1c521514-d267-456c-a66a-e56544965fd3n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/1c521514-d267-456c-a66a-e56544965fd3n%40googlegroups.com?utm_medium=email_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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/aa0085f1-7057-40fb-9539-3c11e152n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/aa0085f1-7057-40fb-9539-3c11e152n%40googlegroups.com?utm_medium=email_source=footer>.
--
.
Gregor Best
b...@pferdewetten.de
--
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/b067d62d-b412-e34f-6b8a-6e727b44d007%40pferdewetten.de.
Re: [go-nuts] Use cases for custom ResponseWriter
net/http/httptest contains an implementation of http.ResponseWriter that's used for testing request handlers in isolation (without spinning up a server). On 17.03.21 03:12, Amit Saha wrote: Hi all, I came across the need for writing a custom ResponseWriter when I wanted to log the response status code. Is there any other use case where this is needed to implement one? Thanks and appreciate any pointers. Best Regards, Amit. -- Gregor Best b...@pferdewetten.de -- 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/dc71f5e6-93e4-8208-f1a5-0ecca4411361%40pferdewetten.de.
Re: [go-nuts] Re: [ANN] New german translations
That somehow reminds me of one of my professors in university who (probably on account of his near-retirement age) insisted on calling recursive descent parsers "rekursive Abstiegszerteiler". On 16.03.21 11:10, Haddock wrote: Anyhow, if I hear how young people are talking nowadays, it makes me sick. Die Funktion wurde "gecalled" und die Exception "gethrown". Sometimes I fear the next generation will not have learned to watch what their mind is doing. I might be wrong. I hope so. Haddock schrieb am Montag, 15. März 2021 um 15:54:02 UTC+1: I agree that Quellcode or Quelltext are the best transalations IMHO other than just using Code HaWe schrieb am Sonntag, 14. März 2021 um 09:11:14 UTC+1: Hello Tim. Translating, that's a hobbyhorse I ride now and then. (Learn something new about Go and improve your English and German in parallel! ;-) No, sorry. There is no public repository. The private one right here under my desk is ... well ... private. Now, about you taking up translating: that's a great idea. Many of the Go documents could be worth the effort; the blog posts about modules come to mind. (Write to me off-list if I can be of any help; email address is in the top box of any of the translations.) (BTW there had been a german version of the Tour of Go from 2015 by one Michael Faschinger, but alas, that seems to be no longer accessible.) I'm still thinking about rufen vs. aufrufen; since it's not only about calling functions but about exported types and variables as well, the appropriate word could be "benutzen". (Changes will be in the next release; following Go 1.17.) So long HaWe a2800276 schrieb am Freitag, 12. März 2021 um 15:14:38 UTC+1: "Kode" really seems nonstandard to me. It really pops out. I'd definitely spell it "Code" in German and even then it seems like colloquial usage. I'd prefer Quellcode or Quelltext or Programm. "Kode aus einem externen Paket rufen" should really be "aufrufen" no matter how you feel about "Kode" :) Are you looking for help with the translations? I'd be happy to work with you on them for a while. Is there a repo anywhere? -tim On Thursday, 11 March 2021 at 20:53:43 UTC+1 HaWe wrote: Thanks for your comments. It's nice when one's work is appreciated. About choice of words, have a look at the "Wörterliste". The link is in the box at the top. About Spelling: that seems to be a question of age. I learnt the word "Kode" long before I came across computers (but I do use "Computer" in german sometimes). Uli Kunitz schrieb am Mittwoch, 10. März 2021 um 21:53:04 UTC+1: The authority on German Orthography, duden.de <http://duden.de>, recommends the writing Code but allows Kode as well. On Wednesday, March 10, 2021 at 7:34:05 PM UTC+1 Haddock wrote: I don't know about using the word "Kode" in German. I've never seen it different than with c as in English. Whatever, you took a big effort and did a very nice job. Thank you! HaWe schrieb am Dienstag, 9. März 2021 um 17:26:48 UTC+1: Just finished german translation of the two new tutorials: https://bitloeffel.de/DOC/golang/getting-started_de.html <https://bitloeffel.de/DOC/golang/getting-started_de.html> https://bitloeffel.de/DOC/golang/create-module_de.html <https://bitloeffel.de/DOC/golang/create-module_de.html> Maybe that helps some newcomers. In the menu you'll find all the other Go documents I translated over the years. I tried to keep them up-to-date. -- 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/64d6b3d3-1b24-4c8e-bddc-3f22c861f281n%40googlegroup
Re: [go-nuts] Run a goroutine until a channel receives a message
Hi,
if `ws.Read` returns after a reasonable timeout, you can perform a
non-blocking receive on the quit channel to see if it has been
closed/something has been sent to it:
select {
case <-quit:
break
default:
// Nothing to do here
}
out, err := ws.Read()
/* more stuff in the loop */
Another approach would be to use a websocket library that supports
passing a context to the Read method (not sure if any of those exists).
For my usual go-to websocket library (github.com/gorilla/websocket), I
usually set a read deadline on the connection in cases like this and
more or less do the nonblocking read as above.
On 13.01.21 12:10, Sankar wrote:
I have a function that must be executed as a go routine infinitely until
a message comes in a channel. For example:
func readWebSocket(ws *websocket.socket, quit chan bool) {
for {
out, err = ws.Read()
log.Println(out, err)
}
}
Now I call this above function as a goroutine from main such as:
go readWebSocket(ws, quit)
where I want the for loop to go on until the `quit` channel receives a
message. The "select" loop seem to work only on multiple channels and
not on a channel + some looping code.
One alternative that I could think of was to create a second goroutine
(third if you include main) to which this readWebSocket can send the
output of "ws.Read" and the select loop can be run there with two
channels (the quit channel and the new channel which gets the "ws.Read"
output) but that would leak this reader go-routine infinitely or makes
the code more complex.
How to handle this situation gracefully in go channels, where I want a
go routine to run until a channel gets a message ?
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/32f04de0-4684-40eb-9b1b-8a9a7ff80602n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/32f04de0-4684-40eb-9b1b-8a9a7ff80602n%40googlegroups.com?utm_medium=email_source=footer>.
--
Gregor Best
b...@pferdewetten.de
--
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/0285534a-fa6e-4c1b-2cee-743fd7e442f7%40pferdewetten.de.
Re: [go-nuts] when do you use sync.Mutex instead of sync.RWMutex
An RWMutex will block all new readers if a writer is waiting to acquire the lock, and that writer will only acquire the lock once all current readers are gone. Depending on the semantics of your application and the frequency of writes, that might constrain the throughput through the section protected by the lock to the rate of writes, especially if the rate of writes and the attempts to acquire the mutex for reading are roughly in the same order of magnitude. On 20.12.20 09:44, 김용빈 wrote: we usually both read and write for a value. not only read, nor write. with that, I feel RWMutex is always right choice. when should I use Mutex instead of RWMutex? -- 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f597de36-b296-4f59-b756-adb1248387f5n%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/f597de36-b296-4f59-b756-adb1248387f5n%40googlegroups.com?utm_medium=email_source=footer>. -- Gregor Best b...@pferdewetten.de -- 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/61638263-b169-e149-6426-ddfc09dfe15c%40pferdewetten.de.
Re: [go-nuts] When does net/http's Client.Do return io.EOF?
Thanks for the replies guys. Looks like we (and our provider) will have to do a bit of soul-searching wrt idempotent API requests. At least it's good to see that we're not entirely off the beaten path with what we're doing :) On 07.12.20 12:58, Axel Wagner wrote: We recently had the same issue. On Mon, Dec 7, 2020 at 11:58 AM Gregor Best <mailto:b...@pferdewetten.de>> wrote: Hi! We're using a 3rd party provider's API to handle some of our customer requests. Interaction with their API consists of essentially POST'ing a small XML document to them. From time to time, `net/http`'s `Client.Do` returns an `io.EOF` when sending the request. For now, the provider always reported those instances as "we didn't get your request". Cursory search in various Github issues and a glance at the source of `net/http` seems to indicate that `io.EOF` is almost always caused by the server closing the connection, but the client not getting the "it's now closed" signal before it tries to re-use the connection. That was what I concluded as well. I think it could theoretically also happen if a new connection is opened and immediately closed by the server. FWIW, `fasthttp`'s HTTP client implementation treats `io.EOF` as "this request needs to be retried", but I don't know how much that knowledge transfers to `net/http`. I think `fasthttp` is behaving incorrectly - in particular, if it also does so for POST requests (you mention that you use them). They are, in general, not idempotent and there is a race where the client sends the request, the server receives it and starts handling it (causing some observable side-effects) but then dies before it can send a response, with the connection being closed by the kernel. If the client retries that (at a different backend, or once the server got restarted), you might end up with corrupted state. AIUI, `net/http` never assumes requests are retriable - even GET requests - and leaves it up to the application to decide, whether a request can be retried or not. Our solution was to verify that all our requests *can* be retried and then wrapping the client call with retries. Is my interpretation of the situation correct? Or are there other circumstances where the request _did_ end up at the remote end and `io.EOF` is returned? I think in general, you can't distinguish (as a client) whether or not the server received the message. For example, you can try a TCP server that immediately closes the connection. The `net/http` client will report an EOF. Though, to clarify: In this test it didn't return `io.EOF`, but an `*url.Error` wrapping `io.EOF`. So if you actually get an unwrapped `io.EOF`, the answer might be different. I guess what I'm asking is: Is it safe (as in: requests won't end up on the remote twice or more times) to retry POST requests when `Client.Do` returns an `io.EOF`? Note that disabling connection reuse (as was suggested by a number of stackoverflow posts) is an option that we'd like to avoid unless there's absolutely no other way to handle this. If I'm correct in my understanding, even disabling keep-alive won't really help - though it might reduce the number of these errors significantly. It will always be possible that the server closes the connection while a request is in-flight. If that is sufficient, a middle-ground might be to reduce the keep-alive timeout on the client (or increase it on the server): https://golang.org/pkg/net/http/#Transport.IdleConnTimeout <https://golang.org/pkg/net/http/#Transport.IdleConnTimeout> In our case, the server was a java server and it used a timeout of 30s, while the go client defaults to a 90s timeout. If you instead use, say, a 20s timeout on the go client, you still get most of the performance benefit of keep-alive, but the client will assume the connection is useless 10s before the server actually closes it. Not ideal, but it should significantly improve the situation. IMO the only real solution though, is to make requests idempotent, e.g. by adding a unique request ID. It's a lot of work and only really effective if it's propagated all the way down. But it's still easier to achieve than exactly-once-delivery :) -- Gregor Best b...@pferdewetten.de <mailto:b...@pferdewetten.de> -- 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 <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a31d42a5-6a81-0579-a380-b268d10f4eb0%40pferdewetten.de <https://groups.google.com/d/msgid/golang-nuts/a31d42a5
[go-nuts] When does net/http's Client.Do return io.EOF?
Hi! We're using a 3rd party provider's API to handle some of our customer requests. Interaction with their API consists of essentially POST'ing a small XML document to them. From time to time, `net/http`'s `Client.Do` returns an `io.EOF` when sending the request. For now, the provider always reported those instances as "we didn't get your request". Cursory search in various Github issues and a glance at the source of `net/http` seems to indicate that `io.EOF` is almost always caused by the server closing the connection, but the client not getting the "it's now closed" signal before it tries to re-use the connection. FWIW, `fasthttp`'s HTTP client implementation treats `io.EOF` as "this request needs to be retried", but I don't know how much that knowledge transfers to `net/http`. Is my interpretation of the situation correct? Or are there other circumstances where the request _did_ end up at the remote end and `io.EOF` is returned? I guess what I'm asking is: Is it safe (as in: requests won't end up on the remote twice or more times) to retry POST requests when `Client.Do` returns an `io.EOF`? Note that disabling connection reuse (as was suggested by a number of stackoverflow posts) is an option that we'd like to avoid unless there's absolutely no other way to handle this. -- Gregor Best b...@pferdewetten.de -- 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/a31d42a5-6a81-0579-a380-b268d10f4eb0%40pferdewetten.de.
Re: [go-nuts] database/sql works when run it, but with test it complains about unknown driver
Maybe you're importing it somewhere else in your main package. In any case, adding an anonymous import in one of your _test.go-files should do the trick. On 15.10.20 03:53, farid sobhany wrote: I am using database/sql to connect to a Mssql server and it works when I run the application. But when I setup a test file and tried to call the function that makes the connection and store it in an instance, it complains about "Unknown driver \"mssql\" (forgotten import?)" I am not importing the driver in the main file and it works fine. Why does it complain when running the test funciton? -- 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e8a43561-551b-44e1-8605-283ce1f064b0n%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/e8a43561-551b-44e1-8605-283ce1f064b0n%40googlegroups.com?utm_medium=email_source=footer>. -- Gregor Best b...@pferdewetten.de -- 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/095d7c8b-251c-8112-ba6d-55cf590e65e2%40pferdewetten.de.
Re: [go-nuts] Go API receive calls twice when hit through browser
One of the requests is likely the browser looking for /favicon.ico.
In cases like this (wondering "what are these requests?") it's usually a
good idea to log things like the actual request URI used and the request
method.
On 25.09.20 11:30, smartaq...@gmail.com wrote:
Team,
Hi all, hope you are doing good.
I've made a small poc api on my windows 10 enterprise machine
```
func main() {
srv := {Addr: ":8000", Handler: http.HandlerFunc(handle)}
log.Fatal(srv.ListenAndServeTLS("certificate.crt", "certificate.key"))
}
func handle(w http.ResponseWriter, r *http.Request) {
// Log the request protocol
log.Printf("Got connection: %s", r.Proto)
// Send a message back to the client
w.Write([]byte("Hello"))
}
```
The moment I call this api using different
browsers(IE/Chrome)(https://localhost:8000) or curl request I receive
these kind of outputs:
1. In browser I receive "Hello" which is correct
2. In golang console prompt I get this log twice: Got connection: HTTP/2.0
Without TLS:
3. But, while making a curl request I get this log & only once:
What is the difference between point 2 & 3. I've tried both tls and non
tls version with browsers but in both the cases logs are coming twice. I
don't know why this favicon.ico call is going.
Am I missing something here. Please help. Thank you
--
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/216a565e-5fae-4e41-b5fb-7af3ff735fc3n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/216a565e-5fae-4e41-b5fb-7af3ff735fc3n%40googlegroups.com?utm_medium=email_source=footer>.
--
Gregor Best
b...@pferdewetten.de
--
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/ff148651-729e-5665-1a53-237764fcee2a%40pferdewetten.de.
Re: [go-nuts] unit test for function which has goroutine
Right, I wanted to write something about the goroutine and forgot about
it. Sorry about that.
The problem here could be that in the code you posted there's nothing
waiting on any result from the goroutine, and if the test exits quickly
enough, it might not get scheduled.
In general, whenever a goroutine is created, you should have some idea
of when and how it gets to run and when it stops running, and how other
goroutines wait for it to do its job.
You could do this for example by controlling the lifetime of the
goroutine with a sync.WaitGroup. Pass in a WaitGroup and call Done() on
it when the goroutine returns (probably as a deferred call), then call
Wait() in some other goroutine (for example in your main function or in
the TestFoo function) so there's some sort of ordering enforced.
In general, you'll need some way of signalling "I'm done copying stuff
from zipReader to zipWriter" in the goroutine, and you'll need to
arrange for some other, longer lived, goroutine to wait for that signal.
On 10.09.20 09:34, Yvonne Zhang wrote:
Thank you Gregor for your quick reply!
Anything special I need to think about this go routine logic in my unit
test. It might be still running after test returns..?
On Thursday, September 10, 2020 at 5:26:13 PM UTC+10
be...@pferdewetten.de wrote:
If I were you, I'd pass in an interface value to functionA with the
signature
type Ber interface{
functionB(io.Reader, io.Writer)
}
(assuming that zipReader is an io.Reader, zipWriter is an io.Writer,
you
may have to adjust this a bit).
Then make your mock functionB a method on a type that implements the
Ber
interface, the same for the real functionB. In unit tests, pass in an
instance of the type with the mock method, in real life, pass in an
instance of the type with the real method.
Note that the types could be as simple as
type mockB struct{}
func (m mockB) functionB(...)
On 10.09.20 09:15, Yvonne Zhang wrote:
> Hi,
> I have a function streaming a zipreader to browser. It is like this.
> func functionA()(body io.ReadCloser, err error){
>
> // some logic to get a zipreader
>
> body, pipeWriter := io.Pipe()
> zipWriter := zip.NewWriter(pipeWriter)
>
> go func(){
> // err := functionB(zipReader, zipWriter)call another
function to
> prepare files and write to zipwriter
> If err != nil{
> zipWriter.Close()
> _ = pipeWriter.CloseWithError(err)
> return
> }
> zipWriter.Close()
> pipeWriter.Close()
> }()
> return
> }
>
> My question is about unit test about this functionA. I have mock for
> functionB. How do I write unit test for functionA with the mock
> functionB. It seems my unit test does not work well when it goes
into
> the goroutine.
> Many 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...@googlegroups.com
> <mailto:golang-nuts...@googlegroups.com>.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/golang-nuts/4ca0817a-f1f7-44a9-be3d-3584bcb61b8an%40googlegroups.com
>
<https://groups.google.com/d/msgid/golang-nuts/4ca0817a-f1f7-44a9-be3d-3584bcb61b8an%40googlegroups.com?utm_medium=email_source=footer>.
--
Gregor Best
be...@pferdewetten.de
--
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/33648e9a-4011-4d02-a07b-01b506cf5cd1n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/33648e9a-4011-4d02-a07b-01b506cf5cd1n%40googlegroups.com?utm_medium=email_source=footer>.
--
Gregor Best
b...@pferdewetten.de
--
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/746e54f8-cefc-9fee-c4e0-8724833e38e8%40pferdewetten.de.
Re: [go-nuts] unit test for function which has goroutine
If I were you, I'd pass in an interface value to functionA with the
signature
type Ber interface{
functionB(io.Reader, io.Writer)
}
(assuming that zipReader is an io.Reader, zipWriter is an io.Writer, you
may have to adjust this a bit).
Then make your mock functionB a method on a type that implements the Ber
interface, the same for the real functionB. In unit tests, pass in an
instance of the type with the mock method, in real life, pass in an
instance of the type with the real method.
Note that the types could be as simple as
type mockB struct{}
func (m mockB) functionB(...)
On 10.09.20 09:15, Yvonne Zhang wrote:
Hi,
I have a function streaming a zipreader to browser. It is like this.
func functionA()(body io.ReadCloser, err error){
// some logic to get a zipreader
body, pipeWriter := io.Pipe()
zipWriter := zip.NewWriter(pipeWriter)
go func(){
// err := functionB(zipReader, zipWriter)call another function to
prepare files and write to zipwriter
If err != nil{
zipWriter.Close()
_ = pipeWriter.CloseWithError(err)
return
}
zipWriter.Close()
pipeWriter.Close()
}()
return
}
My question is about unit test about this functionA. I have mock for
functionB. How do I write unit test for functionA with the mock
functionB. It seems my unit test does not work well when it goes into
the goroutine.
Many 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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/4ca0817a-f1f7-44a9-be3d-3584bcb61b8an%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/4ca0817a-f1f7-44a9-be3d-3584bcb61b8an%40googlegroups.com?utm_medium=email_source=footer>.
--
Gregor Best
b...@pferdewetten.de
--
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/eaeee7dd-8ff0-4dbf-3b5f-bce7617afa18%40pferdewetten.de.
Re: [go-nuts] Golang Custom Application Context
Templates aren't really request scoped though, right? I read the term "request scoped" as "things like request IDs, timing information and maybe user authentication". What I usually do in situations like this is to make the handler functions methods of a `RequestHandler` type which in your case would be the `ApplicationEngine`. Then you create an instance of that struct in your `main` or wherever and register its methods as HTTP handler functions (or whatever protocol you use for transport). On 21.08.20 00:36, Ibraheem Ahmed wrote: In my application I store a map of all my templates (`map[string]*template.Template`) in an `ApplicationEngine` struct, which is my application framework instance. I am currently using the standard `context.Context` to pass request scoped values between my middlewares and handlers. I need a way to access that map of templates in order to render a specific template file. What is the best way to do this? Is storing a map of templates even a good idea? I know that contexts are a controversial issue and just want to hear the available options. I am currently thinking of adopting a way similar to the [gin framework's context](https://github.com/gin-gonic/gin/blob/master/context.go#L56). Gin uses a custom struct that stores a pointer to `gin.Engine`, which is their application framework instance. They then have a `HTML()` function on the context struct, which accesses the template map stored in the `gin.Engine` pointer. While my question is specific to my need, there is a broader discussion here. Should you use custom structs instead of the "standard" `context.Context`? Most web frameworks (gobuffalo, gin, echo) seem to handle it this way, but there seems to be no consensus on if it is a good 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/969f4dc0-f63a-4a9f-b8ff-04457498107en%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/969f4dc0-f63a-4a9f-b8ff-04457498107en%40googlegroups.com?utm_medium=email_source=footer>. -- -- Gregor Best b...@pferdewetten.de -- 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/114994e2-991f-6203-053e-ff6ff79937ef%40pferdewetten.de.
Re: [go-nuts] net.go ok function's c != nil check right ?
Methods are part of the type, not of the value. It is perfectly safe to
call methods on a nil value.
On 03.06.20 09:03, apmat...@gmail.com wrote:
Read function at net.go is like this:
func (c *conn) Read(b []byte) (int, error) {
if !c.ok() {
the ok checks that c is non nil:
func (c *conn) ok() bool { return c != nil && c.fd != nil }
how can c ever be nil ? if it would c.ok() call would crash.
--
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/4969df86-c3ec-4b3f-916d-35a986884362%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/4969df86-c3ec-4b3f-916d-35a986884362%40googlegroups.com?utm_medium=email_source=footer>.
--
--
Gregor Best
b...@pferdewetten.de
--
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/e0049746-28c2-fb9c-922c-a7a32d86b776%40pferdewetten.de.
Re: [go-nuts] MongoDB Connection Failed
Hi Ali,
it looks like there's nothing listening on localhost port 27017. Maybe
the mongod log has some more information for you.
On 06.04.20 15:28, Ali Hassan wrote:
clientOptions
:=options.Client().ApplyURI("mongodb://localhost:27017")// Connect to
MongoDBclient,err :=mongo.Connect(context.TODO(),clientOptions)iferr
!=nil{log.Fatal(err)}// Check the connectionerr
=client.Ping(context.TODO(),nil)iferr
!=nil{log.Fatal(err)}fmt.Println("Connected to MongoDB!")
Error receive when i execute my programCapture.JPG
--
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/bfd30b79-343e-48cc-b853-1d42fe9cd825%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/bfd30b79-343e-48cc-b853-1d42fe9cd825%40googlegroups.com?utm_medium=email_source=footer>.
--
--
Gregor Best
b...@pferdewetten.de
--
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/b2c233d3-c7cb-8c69-4808-fca75d818403%40pferdewetten.de.
Re: [go-nuts] go build output depending on project structure
Hi, it looks like my initial reply wasn't entirely correct. It should build if you pass in both the `.go` file and the `.c` file. On 18.03.20 15:02, Nitish Saboo wrote: Hi Gregor, nitish main.go node.c node.h I compiled using 'go build -v -x main.go' But if my cgo directive is defined in main.go, this should have compiled successfully..right? But it fails with the following whereas 'go build -v -x' works fine. /tmp/go-build439591561/b001/_x002.o: In function `_cgo_5637ad3d75e4_Cfunc_load_pattern_db': /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' collect2: error: ld returned 1 exit status package main //#include //#include "node.h" import "C" import ( "fmt" _ "fmt" "os" "path" "unsafe" ) Please let me know what am I missing here? Thanks, Nitish On Wed, Mar 18, 2020 at 7:20 PM Nitish Saboo <mailto:nitish.sabo...@gmail.com>> wrote: Hi Gregor, Got your point.Thank you for your response. That explains why the binaries have different names post compilation. Thanks, Nitish On Wed, Mar 18, 2020 at 7:06 PM Gregor Best mailto:b...@pferdewetten.de>> wrote: Hi, In both `go build main.go`-examples, you tell the compiler to _only_ build `main.go`. In your first example, `main.go` probably imports both `util` and `lib` (you might want to give them less generic names by the way). The go compiler thus knows "to build `main.go`, I need to build both `util` and `lib` and link them in". In the second example, it has no way of knowing where `load_pattern_db` comes from, since you didn't tell it to compile a file that defines that function. The examples where you omit the `main.go` tell the compiler "build the package in this directory", which includes all `.go`-files in the directory. `node.c` and `node.h` are likely built because of `cgo` directives in `a.go`. The compiler and linker did exactly as you told them to. On 18.03.20 14:17, Nitish Saboo wrote: Hi, *Case 1 -- * I have a project called 'nitish' where the folder structure looks like the following: nitish main.go util util.go lib node.c node.h a.go When I try compiling this project in the following ways: 1) go build -v - x >> This creates a binary called 'nitish' 2) go build -v - x main.go >> This creates a binary called 'main' ldd output of both the binaries is the same. *Case 2 --* Now, when I restructure the project 'nitish' in the following manner: nitish main.go util.go node.c node.h a.go When I try compiling this project in the following ways: 1) go build -v - x >> This creates a binary called 'nitish' 2) go build -v - x main.go >> This error out with the following: /tmp/go-build074530518/b001/_x002.o: In function `_cgo_8eab385aa676_Cfunc_load_pattern_db': /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' collect2: error: ld returned 1 exit status 1) In Case 1, why the binaries are created with different names though both the binaries have the same 'ldd output' and work the same manner? 2) Why we see an error with the command 'go build -v - x main.go' in Case 2 but not in Case 1? Thanks, Nitish -- 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALjMrq6gpXPbED%2BK2xiOKYvRg08FZwkjoPSUaGg%3DFu5hKP-%2BKQ%40mail.gmail.com <https://groups.google.com/d/msgid/golang-nuts/CALjMrq6gpXPbED%2BK2xiOKYvRg08FZwkjoPSUaGg%3DFu5hKP-%2BKQ%40mail.gmail.com?utm_medium=email_source=footer>. -- -- Gregor Best b...@pferdewetten.de <mailto:b...@pferdewetten.de> -- 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 <ma
Re: [go-nuts] go build output depending on project structure
Hi, In both `go build main.go`-examples, you tell the compiler to _only_ build `main.go`. In your first example, `main.go` probably imports both `util` and `lib` (you might want to give them less generic names by the way). The go compiler thus knows "to build `main.go`, I need to build both `util` and `lib` and link them in". In the second example, it has no way of knowing where `load_pattern_db` comes from, since you didn't tell it to compile a file that defines that function. The examples where you omit the `main.go` tell the compiler "build the package in this directory", which includes all `.go`-files in the directory. `node.c` and `node.h` are likely built because of `cgo` directives in `a.go`. The compiler and linker did exactly as you told them to. On 18.03.20 14:17, Nitish Saboo wrote: Hi, *Case 1 -- * I have a project called 'nitish' where the folder structure looks like the following: nitish main.go util util.go lib node.c node.h a.go When I try compiling this project in the following ways: 1) go build -v - x >> This creates a binary called 'nitish' 2) go build -v - x main.go >> This creates a binary called 'main' ldd output of both the binaries is the same. *Case 2 --* Now, when I restructure the project 'nitish' in the following manner: nitish main.go util.go node.c node.h a.go When I try compiling this project in the following ways: 1) go build -v - x >> This creates a binary called 'nitish' 2) go build -v - x main.go >> This error out with the following: /tmp/go-build074530518/b001/_x002.o: In function `_cgo_8eab385aa676_Cfunc_load_pattern_db': /tmp/go-build/cgo-gcc-prolog:86: undefined reference to `load_pattern_db' collect2: error: ld returned 1 exit status 1) In Case 1, why the binaries are created with different names though both the binaries have the same 'ldd output' and work the same manner? 2) Why we see an error with the command 'go build -v - x main.go' in Case 2 but not in Case 1? Thanks, Nitish -- 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALjMrq6gpXPbED%2BK2xiOKYvRg08FZwkjoPSUaGg%3DFu5hKP-%2BKQ%40mail.gmail.com <https://groups.google.com/d/msgid/golang-nuts/CALjMrq6gpXPbED%2BK2xiOKYvRg08FZwkjoPSUaGg%3DFu5hKP-%2BKQ%40mail.gmail.com?utm_medium=email_source=footer>. -- -- Gregor Best b...@pferdewetten.de -- 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/d23423e6-f204-8e63-436b-aa3730013392%40pferdewetten.de.
Re: [go-nuts] Mem-Leak in Go method
This might be a dumb question but...
From reading the code, I assume that the `pattern_db_new()` does some
sort of allocation of a new pattern DB. I don't see any code releasing
the pattern DB. Is that just missing from your post or something that
some automatic mechanism does?
If not, that might be your leak.
On 09.03.20 12:33, Nitish Saboo wrote:
Hi
Following are my Go code and C header file and C wrapper code
parser.go
==
var f *os.File
func LoadPatternDB(patterndb string) {
path := C.CString(patterndb)
defer C.free(unsafe.Pointer(path))
C.load_pattern_db(path,
(C.key_value_cb)(unsafe.Pointer(C.callOnMeGo_cgo)))
}
//export ParsedData
func ParsedData(k *C.char, val *C.char, val_len C.size_t) {
f.WriteString(C.GoString(k))
f.WriteString("\n")
}
cfunc.go
/*
#include
// The gateway function
void callOnMeGo_cgo(char *k, char *val, size_t val_len)
{
void ParsedData(const char *k, const char *val, size_t val_len);
ParsedData(k, val, val_len);
}
*/
import "C"
node.h
===
#ifndef TEST_H_INCLUDED
#define TEST_H_INCLUDED
#include
typedef void (*key_value_cb)(const char* k, const char* val, size_t
val_len);
int load_pattern_db(const char* file, key_value_cb cb);
#endif
node.c
-
int load_pattern_db(const gchar* file, key_value_cb cb)
{
patterndb = pattern_db_new();
pattern_db_reload_ruleset(patterndb, configuration, file);
pattern_db_set_emit_func(patterndb, pdbtool_pdb_emit_accumulate, cb);
return 0;
}
I am calling '*LoadPatternDB*' method in my parser.go file that makes
a cgo call '*C.load_pattern_db'* where I am passing a callback
function to the C code.
The C code is a wrapper code that internally calls some syslog-ng
library apis'
What I observed is:
1)As soon as I call LoadPatternDB() method in parser.go there is some
increase in memory consumption(some memory leak).Ideally that should
not have happened.
2)To verify if the C code had some issue, I called the C wrapper code
method '*load_pattern_db*' from my main.c in the following manner to
completely eliminate Go code here.What I found is there is no increase
in memory consumption after every call ('load_pattern_db' was called 5
times).Hence there is no memory leak from C code.So the issue lies in
the Go code in '*LoadPatternDB*' method in parser.go
main.c
===
void check(char *key, char *value, size_t value_len)
{
printf("I am in function check\n");
}
int main(void){
char* filename = "/home/nitish/default.xml";
key_value_cb s = check;
int i;
for (i=1; i<=5; i++)
{
load_pattern_db(filename, s);
printf("Sleeping for 5 second.\n");
sleep(5);
}
printf("Loading done 5 times.\n");
return 0;
}
3)Can someone please guide me and help me figure out the mem-leak in
'LoadPatternDB' method in parser.go at very first glance? Is the
callback function pointer an issue here ?
4)What tool can I use to check this mem-leak ?
Thanks,
Nitish
--
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CALjMrq5cAJ19CQ8OmMPSJmVB1P3t4hE0CKZ4HsEsH-mp6zm3Ng%40mail.gmail.com
<https://groups.google.com/d/msgid/golang-nuts/CALjMrq5cAJ19CQ8OmMPSJmVB1P3t4hE0CKZ4HsEsH-mp6zm3Ng%40mail.gmail.com?utm_medium=email_source=footer>.
--
--
Gregor Best
b...@pferdewetten.de
--
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/fee07a13-e3d7-4a2e-6a6c-fdb11140ce21%40pferdewetten.de.
Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with earlier versions
This looks like fallout of the 1.14 changes that made Goroutines preemptively schedulable. It seems likely that this code hasn't worked before either, just that the failure cases were masked because less signals got delivered (and thus had less chance of interrupting system calls). On 26.02.20 12:34, Peter Kleiweg wrote: This is with go version go1.14 linux/amd64 Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg: With Go version 1.14 I get a lot of errors when I run: go test -v github.com/pebbe/zmq4 <http://github.com/pebbe/zmq4> I didn't see this with Go 1.13.8 or any earlier version. Is this a problem with Go 1.14, or am I doing something wrong and just got lucky until now? How do I debug this? The errors are different for each run. Below is a sample of some errors. Line numbers are not always accurate, because I inserted some calls to test.Log(). === RUN TestSocketEvent TestSocketEvent: socketevent_test.go:73: rep.Bind: interrupted system call === RUN TestMultipleContexts TestMultipleContexts: zmq4_test.go:131: sock1.Connect: interrupted system call freeze: === RUN TestMultipleContexts ^CFAIL github.com/pebbe/zmq4 <http://github.com/pebbe/zmq4> 30.226s freeze: === RUN TestMultipleContexts TestMultipleContexts: zmq4_test.go:148: sock1.RecvMessage: expected [tcp://127.0.0.1:9997 <http://127.0.0.1:9997> tcp://127.0.0.1:9997 <http://127.0.0.1:9997>], got interrupted system call [] ^CFAIL github.com/pebbe/zmq4 <http://github.com/pebbe/zmq4> 21.445s freeze: === RUN TestSecurityCurve ^CFAIL github.com/pebbe/zmq4 <http://github.com/pebbe/zmq4> 31.143s freeze: === RUN TestSecurityNull TestSecurityNull: zmq4_test.go:1753: server.Recv 1: resource temporarily unavailable ^CFAIL github.com/pebbe/zmq4 <http://github.com/pebbe/zmq4> 44.828s === RUN TestDisconnectInproc TestDisconnectInproc: zmq4_test.go:523: Poll: interrupted system call TestDisconnectInproc: zmq4_test.go:623: isSubscribed === RUN TestHwm TestHwm: zmq4_test.go:823: bind_socket.Bind: interrupted system call TestHwm: zmq4_test.go:1044: test_inproc_bind_first(0, 0): expected 1, got -1 freeze: === RUN TestSecurityPlain ^CFAIL github.com/pebbe/zmq4 <http://github.com/pebbe/zmq4> 46.395s === RUN TestPairIpc TestPairIpc: zmq4_test.go:1124: client.Send SNDMORE|DONTWAIT: interrupted system call -- 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cdb7319d-542a-45ab-842b-bc1b5d838e93%40googlegroups.com <https://groups.google.com/d/msgid/golang-nuts/cdb7319d-542a-45ab-842b-bc1b5d838e93%40googlegroups.com?utm_medium=email_source=footer>. -- -- Gregor Best b...@pferdewetten.de -- 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/09df487b-31c2-11a5-4195-1968fb5a7f8e%40pferdewetten.de.
