[go-nuts] Re: Why is the reason that the flame graph in go pprof rotated 180 degrees?
180 degrees in respect to what? ;) I'd argue callgraphs have no "natural" orientation, top to bottom is as good as bottom to top or left to right (right to left feels off to me, but I read left to right, so I assume that's just a matter of familiarity) On Monday, 12 June 2023 at 14:26:30 UTC+2 fliter wrote: > Why is the reason that the flame graph in go pprof rotated 180 degrees? > > The reason I can think of is that it seems that this conforms to the func > calling order from top to bottom. > > Thanks for anyone's discussion and replies > -- 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/63777934-a70d-4e2d-bc81-c72d3dd4fa27n%40googlegroups.com.
[go-nuts] Re: Short Variable Declarations Are Oversold
import “os”
func main() {
file, _ := os.Open(os.Args[1])
myfunc(file)
}
func myfunc(file ???) {
}
What type should I use to declare “file” in the parameter list for
myfunc()?
This argument doesn't seem logical to me. If I fully declare `file` in this
case, I also have to know which type to declare it as:
var file ???;
file, _ = os.Open(...)
This will also be a "distraction and waste time". I'm all for explicit
declarations in cases where they add clarity, but in idiomatic cases, I
don't feel it adds anything useful.
Additionally, in cases where I am creating a new function to work with the
variable, surely I'm aware of more context concerning the API, e.g. in the
example, I'll assume `file` has `Read` and `Close`, but passing the
variable along, I would assume the operation on the variable will be more
involved and requiring reading the documentation anyway ...
-tim
--
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/f6c9bafb-50a9-4e40-b091-59988417ebffn%40googlegroups.com.
[go-nuts] Re: Quick poll: Which of these declarative UI trees looks the most legible to you?
To be honest: on first glance, they all look identical to me apart from the missing AddClass statements in the last example. Would it be possible to have some examples with less subtle differences? ¯\_(ツ)_/¯ sorry -- 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/535576c2-4195-4939-b298-eb6c55bf621bn%40googlegroups.com.
Re: [go-nuts] What is the point of gzip Reader.Close?
> > So I think it can be safe to omit > using gzip Reader Close in the general case. > In the general case it's also safe to ignore all errors, because by definition they only occur in exceptional conditions . More practically though, most programmers would probably prefer to follow guidance provided by the authors of the library they are using because by virtue of having written the library, the authors probably understand not only the library's implementation and technical constraints better than the user but also tend to have a better grasp of the problem domain. As a rule if I feel that the author of libraries I intend to use are totally inept morons and can't be trusted to not ask me to arbitrarily call random unnecessary functions I would shy away from using their library altogether. -- 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/972526dd-a1a8-4c01-a8ac-6cb8591162f7n%40googlegroups.com.
[go-nuts] Re: [ANN] New german translations
"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, 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/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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/befdb422-6afb-4595-a7fc-d1ada0a02e65n%40googlegroups.com.
[go-nuts] Re: crypto/tls/generate_cert.go: Should it be used? And how can it be used?
On Sunday, 29 November 2020 at 22:09:24 UTC+1 Jeroen N. Witmond wrote: > > In trying to find out how to do this I came across (closed) > https://github.com/golang/go/issues/19900 As a result I found another way > to invoke it: go run `locate generate_cert.go` host 127.0.0.1 > --rsa-bits=2048 --ca > > Should the comment in the example of https://golang.org/pkg/net/http/#example_ListenAndServeTLS be changed to be more exact in the way crypto/tls/generate_cert.go can be > invoked? Or should crypto/tls/generate_cert.go not be referred to at all? I think rsc's comment in the issue says it all: > I don't think we have committed to writing a cert generation tool appropriate for production use. The generate_cert.go program is a simple program for writing tests. Typically, you would use openssl to generate production certs. You could use the functionality in `crypto/tls` to write your own tool, though. And if you want to distribute a binary, 'go build `locate generate_cert.go`' (taking into account the caveat about more than one file with that name mentioned above.) My feeling is that the documentation in ListenAndServeTLS (which is an inline comment in example code) is meant more as a helpful hint on how to generate a quick and dirty certificate for testing. -tim > > > > Should I open an issue about this? > > Jeroen. > > -- 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/36856340-5c62-46f7-9a9f-a657de22068bn%40googlegroups.com.
[go-nuts] Re: pure-go implementation of sqlite
> > is there (or is somebody working on) a pure-go implementation of sqlite ? > or at least a subset of it, to be able to read sqlite files ? > > -s > > PS: I know about the (by now) canonical implementations > (mattn/go-sqlite and others) but a completely go-based solution would > facilitate deployment and development across devs machines... > sqlite is a bit of a special case, because the C implementation IS sqlite, they have a very stable development and testing setup and my trust in sqlite is basically trust in the developers of the C code. I don't see the advantage of having a Go implementation, expect for the sake of Go purity... Can you elaborate a little bit on the motivation? I've been using go-sqlite on both amd64 and arm64 with absolutely no problem. -- 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/4a05f73f-8915-419d-b9cd-459d41e2e485o%40googlegroups.com.
[go-nuts] Re: crypto data types
> > > looking for guidance on how to get an rsa.PublicKey from id_rsa.pub > seems like I can parse the id_rsa.pub contents and get a ssh.PublicKey but > how do I transform this into an rsa.PublicKey > i need the coersion in order to use other support services. > > Please consider whether this is really what you need to be doing. If you're being provided with a id_rsa.pub file (presumably from a .ssh configuration directory) you will very likely be performing ssh operations, which are ideally left up to the ssh library to perform. If you have a very exotic usecase an know what you are doing, the ssh package uses the crypto.rsa package internally to parse the ssh keyfiles, so just have a look at the implementation there: https://github.com/golang/crypto/blob/master/ssh/keys.go#L262 Good Luck! -- 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/1d89c44c-10a4-4379-87a1-0b5da6c81460%40googlegroups.com.
