Re: [go-nuts] go: go.mod file not found in current directory or any parent directory; see 'go help modules'
Dnia 2024-03-25, o godz. 11:58:57 Kurtis Rader napisał(a): > Please don't use screenshots for plain text. Uhhh... and do delete images on the reply, please. That said: Thank you for reacting to screenshots posted :) -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20240328235328.203c565c%40xmint.
Re: [go-nuts] go1.21.0 panics when loading plugin
Dnia 2023-08-08, o godz. 18:11:56 Bernd Fix napisał(a): > After switching from go1.20.7 to go1.21.0 one of my applications > compiles without warnings or errors, but fails at run-time with the > following panic when loading a plugin: IIRC release notes tools now are version aware, so likely you need to bring all go.mod's version to state 1.21.0 hope this helps, > Cheers, Bernd. > -- 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/20230812181144.3992cea8%40xmint.
[go-nuts] The double caret statement
The double caret statement aka "erret" or "bat return") ad-hoc specification.
"^^" (erret) statement specify the conditional execution of a following
terminating statement, the condition being a built-in check whether any of the
function F named result parameter of interface type _error_ is not nil.
ErretStmt = "^^" ( ReturnStmt | Block ) .
If ErretStmt is followed by a block, this block must itself be a terminating
statement too.
There is an implicit semicolon added to the leading caret ie. ;^^
In plain words:
When code execution reaches the double caret statement all named result
parameters of error type
are evaluated for being nil. If any of those is not nil a terminating
statement is executed.
Otherwise control flow passes to the statement next to it.
func ParseFile(filename string) e error {
fh, e := os.Open(filename) ^^ return
defer fh.Close()
x, e := tryparse(fh) ^^ {
logSmth(e)
return
}
// ...
return
}
Reference thread:
https://groups.google.com/d/msgid/golang-nuts/18e49891-9012-433d-89ce-3dfcc0625cedn%40googlegroups.com
P.S. That is for YetAnotherOfThousandOfGoErrorHandlingIdeas being archived ;)
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20230803014052.1f3d9d1b%40xmint.
Re: [go-nuts] Error handling
Dnia 2023-07-29, o godz. 22:57:15
DrGo napisał(a):
> This involves introducing a new keyword "orelse" that is a syntactic sugar
> for an "if err!=nil" block.
You can implement it as a snippet under any editor in use today.
If your goal is to personally have it in just one line, you can turn off gofmt
and write `; if err !=nil {; return err }`
I'd like to point out that considering
> It is an error to not return an error from an orelse block.
The `return err` in examples still is a boilerplate, so the overall savings are
just four utf-8 bytes, ie. {\n}\n.
I understand sentiment, 'cos there is a huge camp of devs claiming that any
error handling proper is one that is done by something/someone up the
callstack, even future-me — for this camp idiomatic Go can be annoying.
But note that for the most pleasant coder experience the `orelse return err` is
way too much of text to write.
I would better stay with ^^ digraph instead. Lets name it a 'bat operator'.
func CopyFile(src, dst string) error {
r, err := os.Open(src) ^^
defer r.Close()
w, err := os.Create(dst) ^^
defer w.Close()
err = io.Copy(w, r) ^^
err = w.Close() ^^
}
> It also works well with named returns. e.g.,
func returnsObjorErro() (obj Obj, err error) {
obj, err := createObj() ^^ //returns nil and err
}
> otherwise ^^ is like "else" so e.g., it can be followed by a block if
> additional cleanup or error formatting etc is needed before returning, eg
w, err := os.Create(dst) ^^ {
return err
}
P.S — bat operator is easily implementable in an IDE with
onFileOpen/onFileWrite hooks.
Its the piping of content to tools (VSCode and GoLand) that bars me from
personally using it.
Hope this helps,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20230802225759.198a4de2%40xmint.
Re: [go-nuts] Please consider voting to reopen Golang subreddit
Dnia 2023-06-23, o godz. 23:50:32 Amnon napisał(a): > Sorry, but I have been away and missed the context. > What is the protest about? Reddit's decision to sink all good free tools that allow people (mods) to work several hours per day keeping their communities free of propaganda and scams. > > What has redit changed? APIs that were free to access by third parties will be priced as gold. > Thanks yw. P.S. It is worth mentioning that Reddit *has* a good reason to close APIs that are abused by A"I" businesses. Just there is no will to make such changes robust, IMO, as it would cost. It seems to me that current Reddit's brass has no faintest idea how many $millions monthly mod's work is worth. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20230624153919.43160eba%40xmint.
Re: [go-nuts] Best practice for "main.go" to access members of a structure in the real package
Dnia 2023-02-17, o godz. 19:18:23 Pat Farrell napisał(a): > Which is a good start. It works great if I capitalize all the variables. > But I really don't want to make all of the variables in the struct be part > of my public API. then make GetSmth methods on that struct. That will be your public api. > They are all implementation details. I need to be able to > initialize various variables in the GlobalVars struct from my 'main.go' If you use flags package you will have other fields exposed though. I personally stopped use flags, due to too much chores around it. Here is mine's substitute I prefer for simple cmd scripts: https://github.com/ohir/mopt > But I've been using file/package level vars. This is clearly a bad thing. It is perfectly OK if these are set once from the cmdline. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE (cc due to thread age) -- 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/20230227192857.674ad274%40xmint.
Re: [go-nuts] How long does it take to import packages?
Dnia 2022-08-31, o godz. 00:00:41 ag9920 napisał(a): If you are in windows ecosystem exclude your development areas, including go installation and gocache from antivirus "heuristics". While at last most of AV vendors "discovered" that Go exists and it has its own linker, some dutifully sends out home binary artifacts of anything you compile "for heuristic analysis". (Second culprit for "dozens of seconds") can be a misconfigured corporate (or state-wide) proxy. > Hi, recently I've been trying to make my unit test faster. It seems too > much time were spent on initialization. After removing all init() function > in relevant packages. The speed was still very slow.It even takes dozens of > seconds before entering my real unit test function. hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20220831200300.45bcd96a%40xmint.
Re: [go-nuts] pkg.go.dev: navigation index is confusing
Dnia 2021-09-03, o godz. 17:45:27 Markus Heukelom napisał(a): > > @Markus: I normally use browser's search function to get to the function > > and it works well with pkg.go.dev too. > If you vaguely remember a function name, for example "TrimPrefix" (note: > it's actually "StripPrefix"), search obviously doesn't work. It works, highlighting proper places. 57 of them. Just scroll and note highlights. If you do want really concise form to skim the `go doc` tool output is way to go. Just grep for a few letters for the hints: `go doc net/http | grep -i pref` const TrailerPrefix = "Trailer:" func StripPrefix(prefix string, h Handler) Handler `go doc net/http | grep -i pars` func ParseHTTPVersion(vers string) (major, minor int, ok bool) func ParseTime(text string) (t time.Time, err error) Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210904142439.7aff3d84%40xmint.
Re: [go-nuts] pkg.go.dev: navigation index is confusing
Dnia 2021-09-03, o godz. 12:26:39 Axel Wagner napisał(a): > And b) this is not a property of pkg.go.dev - the old godoc and godoc.org > both had the same behavior. > This also behaves the same. Look where StripPrefix is listed here: Hm... Yes. My bad, Axel. I should have checked before hitting "send". :( I misunderstood Markus Heukelom's problem. @Markus: I normally use browser's search function to get to the function and it works well with pkg.go.dev too. @Axel: I sincerely apologize for undeserved and misguided sarcasm. Shame on me. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210903131341.2742b5b0%40xmint.
Re: [go-nuts] pkg.go.dev: navigation index is confusing
Dnia 2021-09-02, o godz. 14:32:05 "'Axel Wagner' via golang-nuts" napisał(a): > On Thu, Sep 2, 2021 at 12:26 PM Markus Heukelom > wrote: > > > So, turns out, the function is actually listed under the type "Handler", > > probably because it implements that interface. > > > > It's a heuristic to find "constructors" of types, which is useful > if you know you want that type and want to know how to get one. Excuse me?! Does above sentence implies that the new shiny docs site (pkg.go.dev) heuristics allow me to find only things I am already intimately familiar with? Uh. Now I am the more glad I got local godoc fork: https://sr.ht/~sircmpwn/godocs.io/ yw, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210903122127.57a89178%40xmint.
Re: [go-nuts] Makefiles for Go Programs
Dnia 2021-08-24, o godz. 07:54:35 Reto napisał(a): > It may be nicer, however the beauty of make is that it is ubiquitous, > everybody already has it. No, not everybody has it. Esp. on Windows host. > With mage, your installation instructions now need to contain how / > where to get mage in the first place, leaving the user with a random > binary somewhere which they probably never ever need nor update again. Nope. If user is going to compile from sources she also needs to install Go compiler and tools. Once she has it the mage is a `go install` command away. Shorter than typical line of "prerequisites" needed by non-developer user on most of linux distros. (If she is about to install binary she does not need mage at all - 99% deployments of Go based apps are just the single executable.) > leaving the user with ... they probably never ever need nor update again. Make does not come alone for end-users. Usually it comes bundled with several hundreds of megabytes of the devel packages user gets after issuing eg. `sudo apt-get install build-essential`. Then she's left with a bit more more unused stuff than a single mage binary. TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210824130426.40fd40c2%40xmint.
Re: [go-nuts] Re: Makefiles for Go Programs
Dnia 2021-08-23, o godz. 19:47:47 Roland Müller napisał(a): > What are the alternatives to Makefile that are used by Go developers? https://github.com/magefile/mage yw. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210823193838.75db5e3a%40xmint.
Re: [go-nuts] Re: Small number change will affect benchmark results
Dnia 2021-07-28, o godz. 19:42:05 Kurtis Rader napisał(a): > [...] I too am mildly annoyed by [Tapir Liu] questions. As I was a few years ago. But let's do Tapir Liu justice: he posted a good manual online [https://go101.org] and he updates it as his knowledge grows. Also his stubborn picking at the tiny bits of the language (and community answers to his drilling) not once gave me that a-ha moment revealing that things I considered POGos really aren't. As annoying his adventures are, he does a favor to the community. Both to novices (with his manual) and to the ol' Gophers too, taming their (my!) self-assurance. > the Go community isn't your private unpaid He has paid us to the bit with his go101.org manual. I often recommend it as the "second view" docs. (Second to the official site). PS. @TapirLiu: > every time you start one of these threads you omit important facts. This stands! You often post too soon. Please remember that this is MAILING list that just happens to have web interface. You do often "thinkk in loud" and I see an inflow of messages to my mailbox. Just let your question grow for a while before you post, will you?:) TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210730021555.06ba5fbb%40xmint.
Re: [go-nuts] proposal: infer module name via version control when running `go mod init`
Dnia 2021-05-11, o godz. 11:14:24 Jon Calhoun napisał(a): > it saves me a handful of keystrokes at best - so I understand if it doesn't > seem > worth the effort. Right. > It feels close enough to the current behavior to be a good addition Gopath is retiring soon. Anyway, Someone needs to do many more keystrokes to int repository anyway. > , but I admittedly haven't explored how easy/hard it would be to implement. Look at the list of currently supported VCSes to get a feel of the task. For the starter: infer module name from a Fossil's checkout file (it is a sqlite db). Hoe this helps > Best, > Jon -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210512132732.0bfc4867%40xmint.
[go-nuts] Do not post images of text, please. [Was: doesn't see the function in the same package(pug/jade)]
Dnia 2021-05-09, o godz. 07:47:21 Денис Мухортов napisał(a): > [image: хелп1.PNG][image: хелп2.PNG] Do not post images of text to programmer's list, please. Read rules at https://groups.google.com/g/golang-nuts TiA, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210510110633.1d8e0516%40xmint.
Re: [go-nuts] I want to help with polish version of "A Tour of Go", how to start?
Dnia 2021-05-04, o godz. 08:08:26 Kamil Ziemian napisał(a): > Hello. > Just on first page. There is "mozesz", when it should be "możesz", with > I don't know where to start. I try to google answer, but found nothing. > Can anyone guide me? https://github.com/golang/tour/blob/master/TRANSLATE Proszę uprzejmie :) > Kamil Ziemian (don't try to spell my name ;)) -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210504211823.285d96f8%40xmint.
Re: [go-nuts] what is a &^= b means?
Dnia 2021-04-24, o godz. 05:42:01 xie cui napisał(a): > what is this op (&^=) means? This is common idiom for "bit clear" in Go Chinese: https://gfw.go101.org/article/operators.html English: https://go101.org/article/operators.html https://golang.org/ref/spec#assign_op https://yourbasic.org/golang/bitwise-operator-cheat-sheet/ Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210424171643.6bf76d41%40xmint.
Re: [go-nuts] Modules... why it has to be so painfull?
Dnia 2021-04-07, o godz. 14:31:07 Slawomir Pryczek napisał(a): > Anyone has an idea for a reasonable solution which will allow easy > refactoring and code organization in packages, in this new model? Idea is here: https://github.com/golang/go/issues/44347 Whether is it reasonable or not — objectively — I can not tell as I am an author. Though I'd like to see other's opinion whether proposed solution would work for them. TC. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210409233400.0aaac9e5%40xmint.
Re: [go-nuts] [Macos/Apple M1] HTTP client requests to ".local" domain adds 5 seconds overhead
Dnia 2021-03-31, o godz. 01:47:43 Jonathan Hedrén napisał(a): > Whenever an HTTP request is sent from a Go application to any of the > ".local" APIs, 5 seconds are added to the response time. https://www.bram.us/2011/12/12/mamp-pro-slow-name-resolving-with-local-vhosts-in-lion-fix/ TL;DR do NOT use .local; keep hosts entries under allowed 10 names. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210331235628.03f8cafc%40xmint.
Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?
Dnia 2021-03-30, o godz. 14:20:29 "'Axel Wagner' via golang-nuts" napisał(a): > FWIW I believe printing every build constraint for every file skipped is > far too verbose, even for -n or -v mode. Both -n and -v modes already are very verbose, for purpose. If I am giving either I expect to see a torrent of information. Now I can see exact compile commands, what is missing and so on but the simple information that a file was excluded isn't there. It might be. > That's notably very different from a distinct flag or command, which > doesn't spam in the common case and can filter the information down > to a more useful subset. Of course it would be better to have specialized flag, eg. "-excluded" > You don't need a regexp. You just need to grep for `// +build`. Heh, `// +build` is-a regexp :) Grep is fast, nonetheless `grep -rn "// +build"` matches this regexp on every line of every file (you also can find -print| but that's yet more to alias and run). Just to print what `build` can just log after reading a few lines it must read anyway. DESIRED: go build -n -excludes -tags bsddebug > >(command config lines elided) > > ./a.go excluded at line 4: // +build darwin freebsd netbsd openbsd > > ./b.go excluded at line 3: // +build lindebug,linux > > ./c.go excluded at line 3: // +build !lindebug,!bsddebug > > ./d.go excluded at line 3: // +build windows > > ./e_windows.go excluded by name constraint (GOOS != windows) > > package github.com/ohir/buildconstr: build constraints exclude all Go > > files in /path.../buildconstr TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210330172839.41ee3f69%40xmint.
Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?
Dnia 2021-03-29, o godz. 20:41:02 fge...@gmail.com napisał(a): > Since the build constraint language is equivalent to a first order logic > language, no guaranteed useful information can be provided in the general > case in a limited time. The build tool decides about exclusion anyway. In the very moment it knows a file is to be skipped it could print (with -n or -v) that constraint line that gave the deciding predicate. There is enough information for our brains to solve a "why we got no valid sources here" puzzle. > grep should be good enough :) Why build a regexp later for something build tool knows in situ? (https://play.golang.org/p/BeYjYFgLTuU) export GOOS=linux cd buildconstr CURRENT: go build -n -tags bsddebug package fairbe.org/ohir/buildconstr: build constraints exclude all Go files in /path.../buildconstr DESIRED: go build -n -tags bsddebug (command config lines elided) ./a.go excluded at line 4: // +build darwin freebsd netbsd openbsd ./b.go excluded at line 3: // +build lindebug,linux ./c.go excluded at line 3: // +build !lindebug,!bsddebug ./d.go excluded at line 3: // +build windows ./e_windows.go excluded by name constraint (GOOS != windows) package github.com/ohir/buildconstr: build constraints exclude all Go files in /path.../buildconstr TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210330140808.20c13b4d%40xmint.
Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?
Dnia 2021-03-29, o godz. 15:17:42 "'Axel Wagner' via golang-nuts" napisał(a): > I still don't understand how you think we should provide this explanation > without solving SAT. ... > What is "builtconstraint_1" and how is it determined by the go tool? My > first impression was that it is supposed to be a build tag (like "cgo"), > which opens up the problems I asked - it's not clear which tag is "at > fault" or how to figure that out. As I understood the OP, it would be nice to have build -n and -v messaging us with short info about the constraint that excluded given file from under build. And I concur. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210329174615.2aeb6dc9%40xmint.
Re: [go-nuts] No generic, part -2
Dnia 2021-03-17, o godz. 14:27:51 "Space A." napisał(a): > Can you provide any proof that there was an open public discussion? Can't you search for yourself? When I submitted my rough counterproposal there were already over 50 others linked at Team's (compile contracts one). Wasn't it a discussion then? Talking current proposal: brackets in syntax are the most visible effect of the Team having open discussion with "us". "We" barked at "unbearable parenthesosis" and "our" voice was taken into account. So please stop stretching this thread — all its yaks already are hairless. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210317125511.46a0698d%40xmint.
Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org
Dnia 2021-03-17, o godz. 02:57:15 mortdeus napisał(a): > This ad should have never been put up to begin with Every time I go to sites with this banner I am being reminded of what have happened to this once democratic country. And not to this country alone. > this community is far more important (and far larger) than America's general > incapability to get along with one another. Not "general incapability", but incapability of some 40% deluded by the Big Lie¹. > Honestly when I saw the ad a few weeks before the election it seriously broke > my heart. If it pains, it works as intended. > this community being impartial to the radical notion that we have to be > willing to accept even white supremacists into our ranks, if they like to > code in the best What about liars, rapists, murderers? Are they ok just because they *like* to code? No, never! Healthy community shuns off toxic elements. > loving and deliberately NON-PARTISANLY inclusive community structure Inclusiveness and tolerance may not, and happily in tech communities now does not, extend to individuals set at destroying either or both. > that ultimately allows us to defeat them at their own game. Empowering evil with tech knowledge diminishes moral people chances to prevail. > All I am saying is we need to take down the "conservatives not welcome here" > sign. Cult of amorality and "supremacy" is contrary to everything that "conservative" means. This is not the only word stolen by nazis, but its theft pains me the most. > And if me saying that offends you It does not offend me, I really enjoyed it — it acknowledged that not all people sold on "fake-right" propaganda feel right. What means that some fogged souls can yet be saved. Mankind invented ostracism exactly for such purposes: to correct harmful behaviors in a non-violent way. EOT. This list is not meant for peddling "fake-right" propaganda. "Evil not welcome here" sign is at the right place. Let it stay. [1] https://en.wikipedia.org/wiki/Big_lie -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210317122048.7639ea91%40xmint.
Re: [go-nuts] Re: [ANN] New german translations
Dnia 2021-03-16, o godz. 03:10:02 Haddock napisał(a): > Anyhow, if I hear how young people are talking nowadays, it makes me sick. >>>> Plato schrieb am Montag, 8. März ungefähr 489 vor Christus: >>>> As we all know, Socrates often said that “The children now love luxury; >>>> they have bad manners, contempt for authority; they show disrespect for >>>> elders and love chatter in place of exercise. Children are now tyrants, >>>> not the servants of their households. They no longer rise when elders >>>> enter the room. They contradict their parents, chatter before company, >>>> gobble up dainties at the table, cross their legs, and tyrannize their >>>> teachers. [https://www.bartleby.com/73/195.html] :) -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210316125737.368c0770%40xmint.
Re: [go-nuts] running tests against benchmarks
Dnia 2021-03-15, o godz. 10:44:50 Jeremy French napisał(a): > So it seems like the logical solution would be to create a test that runs a > benchmark and makes sure the benchmark results are within some acceptable > range. I realize that benchmarks are going to differ from machine to > machine, or based on CPU load, etc. Compare old implementation and new one: https://play.golang.org/p/w9giDccrpNa PS. In a CI pipeline, as we do not know exact HW where tests will run tomorrow, we normalize to a known base. Usually crypto/des suits well as the stable unit of speed. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210316033610.3841d8a7%40xmint.
Re: [go-nuts] No generic, part -2
Dnia 2021-03-15, o godz. 15:08:22 "Space A." napisał(a): > And what's happened to a new "generics" proposal, it also got a lot of > critics Apparently not that lot. Second (publicized) design was for me, and likely for many other "vocal critics", good enough. My personal (and fresh) acceptance stems from a simple fact that with current generics proposal I will be able to do what I've been doing before with code generators. So there is a clear gain - someone who will maintain my code will not be forced to analyze and maintain generators. > A few days after Russ locked it, so nobody can even say a word against it if > they wanted. On this list, that is not locked by Russ, I do not see "massive disapproval of the community". Some people, including me, voiced concerns re expected clutter and re worsened legibility. But these are minor disturbances. We just will learn to read and visualize new meanings in the code. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210315225442.2ea013c3%40xmint.
Re: [go-nuts] insane idea to eliminate CGO latency
On Sun, 14 Mar 2021 12:56:43 +0100 "Elias Naur" wrote: > > It incentivises us to rewrite C codebases into proper Go. > Rewriting (and maintaining!) mature and well-maintained libraries is > impractical. > Rewriting platform-bound APIs (OpenGL, Cocoa) is impossible. > A rewrite is one thing, maintenance is another. Do you have the > resources to match those poured into SQLite or Harfbuzz? Where it is impractical there costs of CGO call (and writing a C/go wrapper to things like a Harfbuzz) likely are offsetted by the amount of CPU work done on C side, or by the amount of human work not done. Where it nears impossible there we are and we will be using wrappers :) Neither I advocated rewrite of everything — but for small to middle things it can be done and pays almost immediately with lower entry and usage costs (eg. https://www.gonum.org/). > Elias -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210314143517.5d7983b0%40macmint.
Re: [go-nuts] insane idea to eliminate CGO latency
On Sat, 13 Mar 2021 22:57:11 -0800 (PST) "Jason E. Aten" wrote: > Iminimize the cost of crossing the CGO barrier from Go code into C code and > back. I personally regard this cost as godsend ;) It incentivises us to rewrite C codebases into proper Go. > Instead of teaching the Go compiler how to better run C code, what if a C > compiler (e.g. clang) was taught to generate code that used the Go stack > and calling conventions. Someone would need to do it, then maintain it. > Theoretically, the cc output "in Go convention" could be linked with Go > code without paying the CGO penalty, no? Not that easy. Elias Naur already said why. > How crazy is this? :) There are more "crazy" solutions that actually work: Eg. if you really need to hook at battle-tested C code that needs no further maintenance, you may try https://github.com/minio/c2goasm It lets you bootstrap fast, then you may aim at a proper rewrite. Caveats: https://github.com/golang/go/issues/40724 https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210314123016.12f59da6%40macmint.
Re: [go-nuts] Brook v20210214 Released – cross-platform strong encryption, undetectable proxy. Open Source via GPLv3
Dnia 2021-02-25, o godz. 19:50:24 txthinking com napisał(a): > Document: https://txthinking.github.io/brook/ There is NO document there, the less txt document. This url wants to load a javascript app. Good telltale about "security". -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210226180423.07bd0f3b%40xmint.
Re: [go-nuts] Error handling
support exceptions.
P.S. You, Robert, could make a gift for others who'd like to have "lucid happy
path view" by amending mainstream IDEs folding code with "fold to finger"
functionality. I mean, let the IDE hide every `if err != nil` {; return err }`
block and display (U+1F446) next to the lhs err symbol instead:
/// Where such code
file, err := f.Open(name)
if err != nil {
return err
}
/// would display folded as
file, err := f.Open(name)
///
That would be way more constructive than our yak-shaving here :)
TC,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20210222153346.2d970dae%40xmint.
Re: [go-nuts] Code markup in golang-nuts
Dnia 2021-02-20, o godz. 23:52:04 Amnon napisał(a): > Slightly off topic. > But is there any way to enhance google groups so that it will support > Markdown? GGroups are n web interface to *mailing lists*. Most pros is subscribed via mail, some (as me) using only MTAs that pass through only plain text. > Or at least provides a simple way to post formatted code without the > indentation being destroyed? Quick check over my mailboxs tells me that some 10% OP originate in the web interface; then yet less followups are posted via web. > People often want post code snippets on this group. > And I have yet to find an easy way to do this. Put your code on the playground, press [SHARE] then copy url and paste in your message. This is the right way to share Go code. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210221172231.43cd5a34%40xmint.
Re: [go-nuts] Error handling
Dnia 2021-02-20, o godz. 16:48:09
Michael MacInnis napisał(a):
> I can tell you most emphatically that I am not proposing not checking
> and/or not handling errors.
I did not stated that you won't. Cited piece was directed at "just return err"
code stressing that it is not that common in the production code, mine's.
> I'd like to know if, for functions like the
> ones just mentioned, a pattern exists for "eliminating
> much of the boilerplate that arises if every error is checked with a rote if
I said twice that for me it is not "boilerplate" but much appreciated feature
of the language whose creators knew and acknowledged that every piece of
code is written once by one developer but is then being read over and over
by way more people than one.
And I have had not less emphatically told that where there is a function
that just returns with err, even in "many places", the bytewise cost of return
is some 30 bytes usually placed by the IDE with three strokes of mine.
For these three strokes where I just return (now):
As a reader I gained clear information that here something was checked then
function just spilled error up *but* I have the surrounding context at sight.
As an author I gained - now or later:
- A ready space to comment on and/or decorate the error value.
- If I am decorating or creating error value, I am right in scope.
- If this is recoverable failure, I can try to recover it now.
> And further if that pattern can be implemented as a library/package
> with acceptable trade offs.
In this thread it was proven that this antipattern can be implemented
as a library/package - using import, then setup, then a call to obscure
function - all to replace a 26 or 30 bytes long idiom - by Michael Ellis.
> I'd like to know if, for functions like the
> If … a pattern exists for "eliminating [ these "ifs" ]
Yes it does exist. I once upon a time did a "fail" package and accompanying
generator to implement such "if-less" pattern to use in a cases where cost
of acquiring a resource is high and a bunch (say 8-10) of such resources is
needed to complete the task. It was a waste of time, as new people need to
be taught to read and understand it anyway. So it was abandoned due to
onboarding issues. It really was not worth the time.
``` go
for fail.With(err) { // bind an error type variable,
s, abort := fail.Simple() // set up a single pass loop
abort.Where(err != nil, !ok, z < 0) // set common "failure" condition(s)
z := z // test z < 0 (a "checked assignment")
r, ok := <-ch // test !ok
x, y, z, err := f(z, r) // test err != nil, then test z < 0
abort.If(x > y) // test x > y (a "plain test")
x, y, err = m(x, y) // test err != nil
return x, y, z, nil // can be prepended by an optional 'pass:'
abort:
fmt.Printf("‖ %s: \t( %s )\n", err.Error(), s.Trig)
return 0, 0, 0, err
}
// output:
‖ failed Test: ( x > y ) // for x > y
‖ failed Assignment: ( !ok ) // for closed ch
‖ failed Assignment: ( z < 0 ) // for z < 0
‖ Whatever err said: ( err != nil ) // for failed f(z, r) and m(x, y)
```
Early iteration (live example) to be seen here:
https://play.golang.org/p/W35BVsZnZ-q
Hope this helps,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20210221171014.2c247c6d%40xmint.
Re: [go-nuts] How do you test an unpublished module?
Dnia 2021-02-20, o godz. 07:52:26 Peter Kleiweg napisał(a): > you *can* tell go.mod that it should use local files instead of a repository. [...] > replace github.com/pebbe/package => > /home/peter/go/src/github.com/pebbe/package In that sense, yes. You point to package directory and there are files :) -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210221014115.7972fe30%40xmint.
Re: [go-nuts] Error handling
Dnia 2021-02-20, o godz. 13:21:09 Michael Ellis napisał(a): > FWIW, I've put together a tiny package that, with some tradeoffs, seems > useful for reducing boilerplate in the common case where a function simply > wants to return an error to its caller. > The code is almost trivial. It consists of two small functions, > ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows: > in the common case where a function simply wants to return an error to its > caller. There is no trade off here for me (an likely many others). It is idiomatic versus weird: 1. hit !er move on coding (in fact MY shortcut puts panic instead of return). 2. USE: import (write) a module, setup defer stack, confuse first-time reader, write a call, move on. Note that both versions on my vim take just one line off the screen estate. This is true for any IDE able to fold. OK - idiomatic would take two lines more if code is viewed in pager or using MS Word. > in the common case where a function simply wants to return an error to its > caller. It is NOT a "common" case. In the "boring" production code we are expected that any service exposed to the end-user will never refuse to work, our code must try really hard to complete, retrying at other server here, then at other city's or continent server room until its real task can be successfully done. Resources (eg. network services) needs to be acquired, then vetted, then operated on, then finally released in a consistent state. So we don't throw "something went wrong" (ie. unhandled exception) up. Nor we do "Return if any error". We do check errors, then retry in loops. Go explicit, IN PLACE handling helps with that alot. TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210221005359.41b6f042%40xmint.
Re: [go-nuts] How do you test an unpublished module?
Dnia 2021-02-20, o godz. 04:10:38 Peter Kleiweg napisał(a): > Suppose I am writing a package that is in its own module, and I want > to test it. Not with unit tests, but with a larger program that uses > other non-standard packages as well. [...] > How do I get this right? > > Is there a way to tell go.mod that it should use local files instead > of a repository, just for the development phase? No. You can not replace *files*. You can use workaround with briliant hack of https://github.com/rogpeppe/gohack Other hack is to have two or more modules you want to tinker with vendored simultaneously to "all interested parties". This can be achieved in Linux as shared mount, on other OS it need to be exact copy. It is tedious but works. Look at https://github.com/golang/go/issues/27542#issue-357818109 and https://github.com/golang/go/issues/37755 to get hints about other hacks people conceived to be able to work on interdependent code. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210220134428.76fd225f%40xmint.
Re: [go-nuts] gofmt return multiple function closures
Dnia 2021-02-19, o godz. 05:52:38 Neehar Vijay napisał(a): > Does gofmt assume tab width of 4 or 8? Gofmt uses ascii tab characters. It is up to readers to set tabs width as they please. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210219162009.66aa6f73%40xmint.
Re: [go-nuts] Re: go get not working in Go 1.16
Dnia 2021-02-16, o godz. 13:57:06 Peter Kleiweg napisał(a): > So why would you ever want to *not* set `GO111MODULE=auto` ? > Because GOPATH mode is gonna to be slayed soon. It is better to use it less and less to avoid future disruption. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210217134713.632efe2f%40xmint.
Re: [go-nuts] Re: How to get VSCode to use different Go env vars for different directories in the same repo?
Dnia 2021-02-14, o godz. 10:54:02 Michael Ellis napisał(a): > I wrote a detailed answer on StackOverflow Thank you. As vscode-go is now curated by the Go team [https://blog.golang.org/vscode-go] I think you should raise issue at https://github.com/golang/vscode-go. Your project layout (original one) seems good and straightforward, and the need for having per-folder environment settings or build-tags is real. It shouldn't be the IDE that dictates Go project structure, IMO. TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210214173156.1a9edbfa%40xmint.
Re: [go-nuts] Error handling
Dnia 2021-02-13, o godz. 17:44:47 Michael MacInnis napisał(a): > I've been playing around with reducing error handling boilerplate You're not alone. Hundreds of us went into such thinking in the first weeks of reading/using Go - yet before we noticed how much more productive we are with Go's "boilerplate" than we were in languages where handling errors (failures) was "a problem of others", including future-us as "others". Perceived consensus of the Go community is that "error handling boilerplate" is a strong feature. I.e. in normal production software you MUST handle failures and you should do it as close as possible to the source of said failure. Go helps with that. Even team's proposal was finally retracted: https://github.com/golang/go/issues/32437 Discussion there is lengthy, but worth reading to sense why wider community considers "boilerplate" as asset. Error handling proposals umbrella: https://github.com/golang/go/issues/40432 > Michael. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210214171250.4377c454%40xmint.
Re: [go-nuts] Possible Go 2 proposal for built-in Remove method for Slices.
Dnia 2021-02-06, o godz. 12:24:59 Martin Schnabel napisał(a): > > A "remove element from _slice_" operation always must make a new array > > and copy all elements that you intend to stay. Current idiom using append > > will do this for you while being frank about costs. > Maybe I misunderstand what you wrote, Uh, neither do I understand it now :) Apparently I shouldn't be replying to the single line that grabbed my fading attention after too long a day; and I certainly should not mindlessly pat "send" in the morning, too. If I recall properly, my mind wandered near subtle fallacies surrounding slice usage https://blog.allegro.tech/2017/07/golang-slices-gotcha.html Nonetheless, I humbly apologize to whomever wasted time trying to guess what I had on mind. TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210207001222.233108e5%40xmint.
Re: [go-nuts] Possible Go 2 proposal for built-in Remove method for Slices.
Dnia 2021-02-04, o godz. 00:30:57 Selahaddin Harmankaya napisał(a): > There are obviously more things to consider Slice is not an array, it is a _view_into_ an array. Many such views into the same array may exist simultaneously. A "remove element from _slice_" operation always must make a new array and copy all elements that you intend to stay. Current idiom using append will do this for you while being frank about costs. See: https://blog.golang.org/slices-intro and: https://www.digitalocean.com/community/tutorials/understanding-arrays-and-slices-in-go Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210206033222.44a6f191%40xmint.
Re: [go-nuts] R.I.P. Michael Jones
Dnia 2021-02-05, o godz. 00:12:56 Jan Mercl <0xj...@gmail.com> napisał(a): > https://www.geospatialworld.net/blogs/goodbye-michael-jones-the-man-who-gave-the-power-of-maps-in-our-hands/ Great man of wisdom he was, :( such a sad day. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210205014840.650bde98%40xmint.
Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?
Dnia 2021-02-03, o godz. 14:04:42 "'Axel Wagner' via golang-nuts" napisał(a): > Maybe it helps to point out that the statements "you should design your > system to thoroughly validate input and reject it if it's invalid" and > "there are contexts, where trying to be as flexible as possible in trying > to make sense of an input" can both be true. Of course that often both are desired. Just rarely we can attain both at once. Thats why I emphasized "in this (security) context". As for the OP problem: the best would be to have a flexible decoder that also returns an indicator what unexpected format discrepancy it forgave. This would be easy to do for static data; I see no easy solution for such signaling on streams though. TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210203193627.23360769%40xmint.
Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?
Dnia 2021-02-02, o godz. 22:26:10 "hey...@gmail.com" napisał(a): > > So having a “meta/relaxed decoder” usually leads to > specification/interoperability/security problems down the road > I respectfully disagree. Since it's only relaxed with regard to decoding, > it follows the robustness principle where you be liberal in what you accept. I disagree with such disagreement in this (security) context. "Robustness" stated as "accept lousy data" is against security principle "vet your input thorough". > Within a system, the encoding should be explicitly defined, but when that > system has to consume base64 data from outside, being liberal actually > avoids interoperability problems. In security context "avoids interoperability problems" may morph to more accurate "avoids preventing access to our systems by an adversary" - as adversaries are known to eagerly and clandestinely interoperate with our software using whatever means we left them to exploit. (Off the hat example: consuming "liberal" JSON input may allow an attacker to disrupt data guarded by a simple MAC scheme.) TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210203133700.36c529f9%40xmint.
Re: [go-nuts] How to improve the parallelism of go routine？
Dnia 2021-02-01, o godz. 11:12:22 Ian Lance Taylor napisał(a): > On Mon, Feb 1, 2021 at 9:33 AM 颜文泽 wrote: > > go version go1.13 linux/amd64 > Goroutines that run for a long time without yielding the processor are > preempted. Since go1.14 TMK. OP is using 1.13. > > I'm not sure how to deal with this phenomenon when I find that the parallel > > performance > > using go routine is not very good when writing database(olap) code. First - use recent Go compiler version, current is 1.15, 1.16 is coming soon. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210202010636.6de705d1%40xmint.
Re: [go-nuts] go build hangs with 1.15.7 on Windows 10
Dnia 2021-01-25, o godz. 11:07:50 "pst...@gmail.com" napisał(a): > I just upgraded to 1.15.7 from 1.13, and I'm not able to compile. Running > go build seems to just hang. In task manager I see a compile.exe task > that's taking no CPU, and an insignificant amount of memory. ... > I have access to a linux server running 1.15.5, and I have no problems > compiling on there. > > Any ideas, or anything else I should check? Check logs of your antivirus software. Use GOTMPDIR and GOBIN pointing to locations free of overzealous AV interventions. Add go compiler binaries to AV exemption lists. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210126112821.0cce2486%40xmint.
[go-nuts] Restrict general type parameter identifiers to be a single uppercase ascii letter.
I'd propose to amend specification so the type parameter identifiers were of A-Z set, ie. single uppercase ascii letter. While it is a current convention, it would be better to have this convention forced by compiler. First to have an additional cue "generics here", second - to close an easy avenue to hide cloudy or malignant constructs in the source. = induced by conversation spotted in other thread: > Carla Pfaff via golang-nuts" wrote: >> m8il...@gmail.com wrote: > On Tuesday, 19 January 2021 at 15:39:25 UTC+1 m8il...@gmail.com wrote: > > > Seems to me that most generics implementations use a capital letter > > abstracted type syntax that I hate. > > This is just a convention and not part of the syntax, which means it's > irrelevant to the discussion about the proposal. You can easily use > lowercase letters/identifiers: https://go2goplay.golang.org/p/eWgJSLNTZw8 -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210120033232.7492029f%40xmint.
Re: [go-nuts] Go Create
Dnia 2021-01-13, o godz. 07:22:52 Rob Pike napisał(a): >Also, one must be sure to remove the replace directive before > releasing the code, which is an easy detail to forget. I'd humbly summon https://github.com/golang/go/issues/26640 here. Opened at the modules advent, still it sees no love from the Team. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210113145309.61f42301%40xmint.
Re: [go-nuts] Signature Switch - third path to Go generics
nly the > binary code needed to satisfy the types in use. This is true also for the Signature switch - it is compiler that picks pieces of code according to the rules (case signatures) set by the programmer. It certainly might be more work for the author of the generic code but for the readers the Go's clarity is preserved, IMO. Not to mention that more work means also less abuse ;). Nonetheless, it is just an ad-hoc idea stem from the partisan fights I read past year. One to be looked at in leisure time and exercise on the paper, if at all :) Happy New Year! -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210101062911.39633675%40xmint.
[go-nuts] Signature Switch - third path to Go generics
I regard current Team's proposal a way better than the first iteration. But -
while I see a need for generic way to write common code, I also share
concerns about readability and future abuse of the materialized Go generics
being similar to "the other languages". I consciously did not patricipate in
the
[Generics, please go
away!](https://groups.google.com/g/golang-nuts/c/LEEuJPOg0oo)
bikeshed, but I would like to share an idea that may possibly reconcile both
camps.
"Signature switch" - readable generic code preserving the Go way.
Generic function declaration is
https://golang.org/ref/spec#Function_declarations
with at least one type in the Signature given as the ascii character "+"
followed
by single capital ascii letter, further reffered to as "TypeLetter"; and with a
single,
non empty, signature switch present in the function body:
func f (x +T) (r +R) { // generic function
switch func.(type) { // Signature Switch here. Resolves at COMPILE
TIME.
case func(x int) (r int): // call-site signature to match
r = x/2 // instantiated code, T and R are now
ints
}
return r
}
More to read at: https://play.golang.org/p/Q1ry4KPoOOJ
Hope this helps,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20201231193635.0d27177a%40xmint.
Re: [go-nuts] Re: Generics, please go away!
Dnia 2020-12-25, o godz. 11:28:54 "Space A." napisał(a): > What a ridiculous bullshit. Please keep discussion here civilized. This is not a proper place for name-calling and expletives. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20201225210239.6f88485d%40xmint.
Re: [go-nuts] Obtaining an efficient hash for Go values
Dnia 2020-12-24, o godz. 06:19:53 Arnaud Delobelle napisał(a): > I did have a look at hash/maphash, but I didn't think it was the right > shaped API for what I am doing. Do not be afraid to just "steal" runtime implementation and tinker with it to get at desired properties. https://github.com/golang/go/blob/master/src/runtime/map.go https://dave.cheney.net/2018/05/29/how-the-go-runtime-implements-maps-efficiently-without-generics Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20201224165055.2cc4d487%40xmint.
Re: [go-nuts] multicasting with encoding/gob
Dnia 2020-12-23, o godz. 13:45:10 meera napisał(a): I'd use flatbuffers. https://google.github.io/flatbuffers/flatbuffers_guide_use_go.html It is possible to extract gob encoded bytes and copy it over multiple receivers but it would be an overkill, likely. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2020122408.64f74859%40xmint.
Re: [go-nuts] Re: Generics, please go away!
Artur Vianna> you can keep writing your standard Go as it never existed. L Godioleskky> those of us who want to ignore them can easily do so Nope. You can neither pretend "it never existed" nor "ignore" no part of the language. You as a programmer are supposed to read and *understand* a lot of other's code before you will start to write your part. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20201223005655.5dfbd492%40xmint.
Re: [go-nuts] Proposal: New keyword returnif (resolves error handling)
Dnia 2020-11-11, o godz. 08:01:37 Jeremy French napisał(a): > I know that's not realistic, and errors are a part of life. > My point is that they're not the main purpose of the code, and thus shouldn't > be taking up (up to) 75% of the code space when I'm trying to read what a > function does. There are fold spells to assist you in almost every editor otherwise suitable for coding. The psychological miracle of the verbose 'if err' block is that in many it spurs a wise laziness: "ok I have typed ife, I have my cursor inside the block, I am in scope, so why not to put my failure-dealing code here, and now". As for personal opinion: the very "return-if" sounds bad to me. It blatantly and loudly encourages "let others care 'bout that" attitude. In real code (that accidentally is not a kitchen-sink math library) dealing with *failures* is the bread and butter. In server's code piece it is not unusual to have some 10 lines of happy path and next 1000 just to deal with failures that *we think* may happen. Next 1000 will appear in the maintenance phase when heavy load will reveal failure scenarios we never thought may exist. The Go team's "try" proposal (I assume you read) was called off for exact same reason: "try" construct has been encouraging what many Go programmers assumed as a bad practice. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2020210510.66da5dc5%40xmint.
Re: [go-nuts] Re: use same for/range code on a hash map but it has different result
Dnia 2020-11-10, o godz. 19:08:10 "'Kilos' via golang-nuts" napisał(a): > I just copy the screenshot in this Do not do that again. It is akin to saying: "it is more convenient for me to hit two keys instead of selecting text and paste it what would effect in four strokes for me". "So now I am asking you for help so you should start to retype my code from the picture and — in case you are using a screen reader due to failing sight you should ask a seeing human what she sees aloud". > The empty picture is the code and it's different results. There are people on this (and many other technical lists) to whom ALL pictures sounds the same. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2020194143.1df13253%40xmint.
Re: [go-nuts] Licence details of github.com/golang/sync
Dnia 2020-10-29, o godz. 06:52:17 Denis Cheremisov napisał(a): > Hi! > At my job we found these additional patents > limitatations https://github.com/golang/sync/blob/master/PATENTS > They makes us impossible to use errgroup (which is, to say, turned to have > pretty poor choice of WithContext signature, so our one is different), so > we have our custom implementation of it with additonal functionality > (errors collector, concurrency limitation), but it is derived from the > original implementation. This list is not a proper venue to gather 'common-sense' legal advice, as such advice will likely be at odds with your real legal standing regarding your software under each next jurisdiction. To be clear and a bit assured about your real situation you should hire a good attorneys in each country of interest or hire a top-tier international law agency then make sure to be very frank with them about what you did, what you do, and what you plan to do with your implementation. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE P.S. My "Common-sense" advice is this: as whole Go ecosystem is under this grant, if it is stands against your planned deeds, you certainly should abandon Go right now and switch to Java or Swift ASAP. There you'll be covered by Oracle's or Apple's voluminouos license agreements that will make the "very close to" problem disappear, as it will be clearly forbidden ;). -- 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/20201029180854.252a754a%40xmint.
Re: [go-nuts] Any embedded scripting language for Go
Dnia 2020-10-21, o godz. 11:01:58 Aravindhan K napisał(a): > Hi, > > I am looking for a way to build interactive app,where user will be giving > instructions to draw as a script,rendering of the script will be displayed > live. There is such one ready, awaiting you: https://goplay.space#draw https://github.com/iafan/goplayspace > I would like to use below 2d drawing package for same, > github.com/fogleman/gg It is being used there, indeed. > Is there scripting language that would be able generate bindings to > arbiratory go packages back and forth? and I could embed it in Go App as > well. Beside mentioned above playspace (that utilizes script that can be understood by 3-4yo kids), there are Go interpreters as well, you might plug in - most recent I am aware of is at https://github.com/traefik/yaegi Hope this helps, > Aravindhan K > -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20201021201731.36215803%40xmint.
Re: [go-nuts] Re: Proposal to add Index operator methods
Dnia 2020-10-06, o godz. 00:56:38 Raanan Hadar napisał(a): > To a gonum user, this proposal is about a 20% improvement and nothing to run > home about. > To a matlab/python programmer, this solves about 80% of their problems and > combining this > with the other benefits of Go is enough to strongly consider switching to Go. > if you have another way to achieve this, I am open In the end of the day, > the question to ask is whether or not we are better off in implementing this. A "better notation" for the minority of language users can be achieved using go generate. Your OP problem* calls for a transpiling tool - one that from the python/matlab input produces boring Go readable also by general Go audience. *[that matlab/numpy accustomed programmers would be more productive using known or similar to known to them syntax] Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20201006161235.45cd9ec7%40xmint.
Re: [go-nuts] ERRORLEVEL issue. Screenshots detected.
Dnia 2020-09-20, o godz. 23:51:19 Walter Weinmann napisał(a): > [image: Screenshot 2020-09-21 084403.png] > [image: Screenshot 2020-09-21 084604.png] > [image: Screenshot 2020-09-21 084819.png] Please DO NOT post screenshots of text to this list. @ Tamás Gulácsi, @ Brian Candler, @ Kurtis Rader Please DO NOT reply to posts containing screenshots of text. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200921114952.03fce76b%40xmint.
Re: [go-nuts] alloc vs totalalloc in memory
Dnia 2020-09-11, o godz. 17:13:22 Alexander Mills napisał(a): > Well why does TotalAlloc keep climbing up (increasing) in my program, | CUMULATIVE: increasing or increased in quantity, degree, or force by successive additions. | It means that every allocation made _adds_ to an ever increasing "cumulative counter". Think a cash register - every single item's price is added to "TOTAL" (sum, cumulative) variable. > but HeapAlloc remains the same? > [image: Screenshot from 2020-09-11 17-12-32.png] Please do NOT post screenshots here. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200912141958.53854308%40xmint.
Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?
Dnia 2020-06-08, o godz. 16:22:24 Robert Engels napisał(a): > it is trivial to limit the input size to something a user could input. With exponential complexity simple regex /(x+x+)+y/ blows up at input of 20 to 30 x-es. See: https://www.regular-expressions.info/catastrophic.html [Cut long explanations... Axel just posted most of what I was writing regarding trade-offs). Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200609002207.0a161adf%40xmint.
Re: [go-nuts] Any solution to hide my source code written in Go and make it a library to develop in Go as well
Dnia 2020-05-17, o godz. 23:13:28 Billy Cui napisał(a): > Looks this works, anyone know the plugin mode is easy crack out the source > code or not? Read IDA Pro manuals, take a look at IDAGolangHelper scripts for it, then do not waste your time on futile obfuscation. It will work only if your lib total expected income is less than $5-10 per your current lines count. Even after recent spike in reverse engineering prices cost of retrieving compileable source from the binary is still below $1 per output line. Many skilled Russian, Romanian and Bulgarian hacking groups who pay for IDA Pro disassembler will gladly take at it. P.S. compileable does not mean understandable at first sight. This further step costs magnitudes more, but for the reuse and small "impedance fitting" purposes is not really needed. Nor it is needed for a possible thief. hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200520154757.56a2c62a%40xmint.
Re: [go-nuts] [ANN] Unik, a Go unikernel capable of running Gio GUI programs
Dnia 2020-04-13, o godz. 11:42:16 Elias Naur napisał(a): > https://eliasnaur.com/unik Thank you. Respect! :) > -- elias -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200413225949.1108690a%40xmint.
Re: [go-nuts] Re: Golang and the mobile framework
Dnia 2020-03-26, o godz. 22:18:40 husam alkdary napisał(a): > which one react-native or Flutter ? and how ? https://www.arputer.com/using-go-library-in-flutter hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200327092110.7cf340dc%40xmint.
Re: [go-nuts] Re: Where is the version number for a golang module declared?
Dnia 2020-03-12, o godz. 19:11:48 Nick napisał(a): > Forgive my ignorance, but why aren't gohack and > in the go.mod file perfectly good replacements for these use cases? > I get the feeling I'm missing something... > why aren't gohack Gohack is an invaluable tool to hack around without need to manual edits of go.mod once a couple of minutes. Note the "hack" in its name, though ;). Note also, that this exact mechanics used for modules could work over repos staying in the GOPATH. For way less code and effort that went into centralized zipfiles solution. > and replace statements in the go.mod Explained in pointed to go.mod.local issue: tl;dr – go.mod changes intended for local tinkering may inadvertently end in the CI pipe. It is cumbersome to do all that dance just to tinker in an early stage of minting something new. > I agree that anything that penalises people for not using Google > services is problematic, but I don't see how that's happening here. TL;DR - IMO, Go community is now being led into the technically unsound dependency off G/cloud infrastructure. Escape paths, still present yet, are full of obstacles and are easy to close in the future, would G wish so. LR: Offline setup is still possible, but now it is cumbersome and full of traps. We somehow went from the self-contained local tree of dependencies' full source – gathered from any of supported VCS repo – to the cloud infrastructure managed by G from where zipfiles (hello npm!) are downloaded then checked against G owned database. In the case of godoc.org sunset [1], it was not even planned for you to run local docs server at all (G backpedaled on this a bit due to a backslash from the community [2]). Still it is G who can decide whether your code deserves to be listed at go.pkg.dev [3]. It now is a well lubricated slope to some future "notarization / approval" process. I am an old frog and I think I can discern whether I am being cooked even if pot I am in is advertised as a comfortable warming device. [1] https://blog.golang.org/pkg.go.dev-2020 [2] https://github.com/golang/go/issues/36747 [3] https://github.com/golang/go/issues/36840 PS. I do not blame the technical team, as IMO this was a "business decission" in upper echelons of Google what dev-team as a G employees, must obey. > Nick -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200313135617.0ec6fdb3%40xmint.
Re: [go-nuts] Re: Where is the version number for a golang module declared?
Dnia 2020-03-11, o godz. 08:22:46 "'Bryan C. Mills' via golang-nuts" napisał(a): > (But note that you can always set up a local HTTP server using the remote > import path <https://golang.org/cmd/go/#hdr-Remote_import_paths> protocol, > and use a local DNS entry and the GOPRIVATE environment variable to tell > the Go command where to find the repo.) The very need for such a workaround tells that something is severely broken. 1. set up local server just to serve what GOPATH provided seamlessly 2. tinker with your /etc/hosts or c:\Windows\System32\Drivers\etc\hosts or /private/etc/hosts. Do it **every time** you want to work locally on a module from other domain. 3. Reconfigure hosts and your local web server **every time** you want to work locally on a next module. Keep all these configs forever, because you may need to maintain your patches 4. do not forget to set up GOPRIVATE, otherwise you will leak to the outer world rinse and repeat on any host you do tests etc We need to dance this quadrille because go tools won't look at the go.mod.local (https://github.com/golang/go/issues/26640) Unfortunately "go.mod.local" was not invented at Google, so chances we would ever have sane G-independent setup are miniscule now. Mind also that GOPATH is now led to the guillotine, to force all this "local server / crafted hosts / GOPRIVATE setup" fun on everyone not willing to share her development setup with the big G. my ¢2 -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200312161646.5c19d89d%40xmint.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
> ("Smart tabs" were mentioned by Manilo in other thread. :)
Uh, it was in this one, excuse me. Got both my and Manilo's mixed.
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20200220155535.5d9624ce%40xmint.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
Dnia 2020-02-20, o godz. 08:57:51
David Riley napisał(a):
> I'm willing to be convinced otherwise. [...]
> a new "magic" tab that won't be supported
This proposal is not about some "magic tab". It is about a gofmt formatting
recipe
that allows for minimal changesets while keeping "pretty" autoformatting of
structs
intact. ("Smart tabs" were mentioned by Manilo in other thread. :)
> Note that any change made is going to wind up producing
> ENORMOUS superfluous diffs the first time anyone uses it
> on existing code that's already been formatted,
This is the very reason for the "comment-mark" existence in this proposal.
Only new code will use it. Once you do a changes to the struct, you then may
chose new formatting as any change under old rules is going to produce
a massive changeset anyway.
Proposed recipe in fact needs none marker, it could as well used heuristics to
set
csPos = tsPos +8, or +16. Marker gives an opt-in switch here.
> - Dave
TC,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20200220155204.0bbf9bcd%40xmint.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
Dnia 2020-02-20, o godz. 09:10:22 Jan Mercl <0xj...@gmail.com> napisał(a): > I believe the absence of any gofmt knobs (opt-ins) is a feature that's > not going away. You can always use your private fork, if you want. I do not want anymore ;) Knob is there _mostly_ because of all the past code in millions of repos. The fixed `csPos := tsPos += 8` would work for most of Go code w/o knob. > most people will not accept code that is not formatted by the > "standard" gofmt. Thats why it can be implemented "by the core team only". TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200220105559.507cdf03%40xmint.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
Dnia 2020-02-20, o godz. 08:25:57 Amnon BC napisał(a): > Good point Jan, and I totally agree. > > I noticed that the proposal states that it can only be implemented by the > core team. > > I don't really understand the statement, as go fmt is written in Go and all > the sources are available online. > So it might be worth expanding this statement to explain why this proposal > can not be implemented by people outside the core team. Because of what Jan mentioned: uniformity. Change of such kind must be agreed upon then implemented thorough all community. The core team is the only entity to wield such power. I work with forked fmt and godoc (even compiler). Once you get hooked to such settings you can not easily get out of it. You also unintentionally cut yourself from easy ways to giving code back. That's a dead-end for an individual (though I must admit that from the business pov it also may give a huge advantage over competitors). -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200220104922.671dddcc%40xmint.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
Dnia 2020-02-18, o godz. 10:16:57 Manlio Perillo napisał(a): > Here is an example of a diff with a lot of noise, where the actual change > is very hard to see: > https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd > Manlio I just posted a brief proposal — keep tabs on it, as I neither have a time for, nor I long for next round of defending the obvious again. https://github.com/golang/go/issues/37299 TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200219192557.54e8cbba%40xmint.
[go-nuts] [Proposal] cmd/gofmt Minimize adjacent whitespace changes on struct layout edits.
Proposal: Minimize adjacent whitespace changes on struct layout edits. With current gofmt rules slight changes to a struct declaration make for avalanche changes across declaration whitespace due to gofmt trying to layout struct declaration "pretty". Produced changeset size make diffs unreadable if any field identifier or type changes its length. 1. Fix relative indent position of the type of the field, then 2. Let code author hint gofmt where comments should line up. Comment-start hint has a form of a "/<" digraph (slash, less-than) put into the comment that follows the opening brace of the block. https://github.com/golang/go/issues/37299 -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200219191658.33dde792%40xmint.
Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields
Dnia 2020-02-18, o godz. 10:16:57 Manlio Perillo napisał(a): > Here is an example of a diff with a lot of noise, where the actual change > is very hard to see: > https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd > > Note that using `git diff -w` is not a solution, since it can only be used > locally. The full diff will be shown by github and friends. Yes. It could be easily fixed with cosmetic changes to gofmt in a way that is tab-width neutral [1] but I doubt it would be seriously considered given current NIH-driven mood of dev's hive. [1] use marker relative to the opening brace hinting at the desired comment position, ie. compute type-start position relative to the opening brace then comment-start position relative to the marker from the comment of the brace line. Adjust both positions modulo 8 rounded up. Field name that gets over past the established type-start position stays over. Done. Everything, except overlong names, lines up on the screen with ts=2, ts=3, ts=4 as well as with ts=8. Changesets contain no whitespace changes, because there is no such gofmt introduced changes anymore — ofc unless you change type identifier past the rounded 8 boundary. Then whole struct will make to the changeset, not just huge parts of it. Hope this helps, > Manlio -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200219031558.77411fc7%40xmint.
Re: [go-nuts] Any chance of not deprecating GOPATH ?
Dnia 2020-02-01, o godz. 18:16:11 Randall O'Reilly napisał(a): > But I really like GOPATH! See: https://divan.dev/posts/gopath/ for some > similar sentiments. I concur! See also https://github.com/golang/go/issues/26640, recently reopened, 2020-02-01 22:50:27 időpontban Tamás Gulácsi a következőt írta: > See the "replace" directive of go.mod. > replace my/pkg => ../../my/other/pkg > Will use that other pkg instead of my/pkg. This still is mostly manual labor, a source of discrepancies and a mess comparing to the GOPATH established flows — it feels especially at early development stage. The flow I would like to have on the belt: 1. set GOPATH, then experiment freely having at hand **all** needed 3rd party and __all_of_my_own__ production sourced locally. The go.mod exists but is empty. 2. In rare cases experiments need not the tip of some package, use go.mod.local not to 'replace' but to pin version/commit only. 3. go mod tidy && go mod release # make the go.mod as of current package shape commit && tag && push # publish, fix version, possibly make to the modules cache -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200202125254.05858299%40xmint.
Re: [go-nuts] [Proposal] Change how gofmt formats struct fields
Dnia 2020-01-30, o godz. 05:50:36 Manlio Perillo napisał(a): > alignment should be done by the editor, not gofmt. What you just said can be translated to: "editors must support Go meaning of tab characters" > Of course the tab is elastic **only** for a struct fields. Now it adds: "editors must also recognize Go struct fields, because tab is ‘elastic’ only there." Tabs (011) are not "elastic" and never were. A fistful of editors in a few IDEs do this — mostly using plugins. Then source read out of this particular environment becomes ugly. > Struct fields are the only block of code that gofmt will align > automatically, and the alignment may change is you add > or remove a field. Gofmt does align struct fields automatically now. Your OP calls to abandon this functionality for the sake of some six editors that have "elastictab" plugins. Nonetheless you mentioned that current state make source control changesets bigger than necessary, and that is a valid point. But it calls for other solution. Namely: === Gofmt should have -u for "unformat" and -g for "format for a git difftool" functionality added. Called with -u it would produce source with minimal whitespace possible — to be used in the commit pipeline. Called with -g on the difftool pipeline it would try to nicely format diff chunk. === > Manlio Perillo Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200130181758.7823d44e%40xmint.
Re: [go-nuts] [Proposal] Change how gofmt formats struct fields
Dnia 2020-01-30, o godz. 00:46:05 Dan Kortschak napisał(a): > I suspect Manlio was referring to something like this > http://nickgravgaard.com/elastic-tabstops/. Could be. So a small correction: s/agreed constant width of the tab/agreed width of the tab/ Where width can be "elastic". No way more or even less will support it though. Even vim-devs refused. Because this "feature" hides misformatted code just off its very author. (Vim since 8.1.105 has vartabs — neither similar nor relevant here). Had world be less divided, I would have proposed to use rusted and forgotten 013 VT char for this purpose. Alas, this would break some of contemporary browsers and editors ;) > Dan -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200130141045.48794ff6%40xmint.
Re: [go-nuts] [Proposal] Change how gofmt formats struct fields
Dnia 2020-01-29, o godz. 09:56:35
Manlio Perillo napisał(a):
> What I propose is to use a tab between the field name and type.
> It is responsibility of the editor or html formatter to align the code.
This ("between") assumes an agreed constant width of the tab representation.
Ie. it will never work as intended in the field as people are using tabwidths
from 2 to 8.
> Manlio Perillo
Hope this helps,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20200130011051.2e18a964%40xmint.
Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends
Dnia 2020-01-26, o godz. 14:51:00 Liam napisał(a): > Google Trends is commonly used to discern public interest in topics, No, in the IT industry GT service is used to the exact opposite. An "interest" in a programming language (or in tech) expressed as a search about it is a viable indicator of how many people have _problems_ with any given language. You just posted the chart showing a spike in problems masses have had with python due to libraries dropping off v2.7 support. > Google Trends is commonly used to discern public interest in topics, Public interest in fashion, diet, politics and outbreaks — could be (modulo astroturfing bots). -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200127014725.53b91027%40xmint.
Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends
Dnia 2020-01-16, o godz. 03:12:49 JuciÊ Andrade napisał(a): > Liam has a point. Go is not attracting attention as it used to do. Go > ceased to generate news. Google Trends are based on searched terms, not on an analysis of some mainstream media headlines. My interpretation of OP linked "flat" line: "Go has matured, its docs and books are so excellent that Go programmers need not to desperately look for a hint from someone else bitten by an obscure piece of the language or of its standard libs". > Other projects attracts attention by aggregating new features often. Other projects attracts searches by pushing features important to tiny but vocal minorities focused on their narrow savings of a keystroke here and there. Then everyone (off this tiny minority) who stumbles upon such "feature" does WTFII? search, often in rush. Go searches raise only with raising number of Go users. Java and C++ searches peak not because there are more users, these peaks because every *existing*, even seasoned user of these languages day to day knows about them less and less. > I think we need to add a killer feature now and then. This is the last thing Go community needs. TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200121174738.365af850%40xmint.
Re: [go-nuts] Go mindshare is low & ~flat, per Google Trends
Dnia 2020-01-15, o godz. 12:34:54 Liam napisał(a): > Google Trends graph showing past 5y of Java, Python, C#, Node.js, Go > > https://trends.google.com/trends/explore?date=today%205-y=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr Posted chart tells in loud that Go users have way less problems with understanding code than users of languages described by curves rising steep. Go searches rise at most linearly with developer population growth. Java and C++ searches are rising despite their respective developers populations shrink. Yesterday introduced Java's "pinned-pointer" will make vast cohorts of Java developers search for descriptions of encounters with that mysterious beast — from day one and for months and years to come. It will be seen in Google Trends — as intended. Trends (in technology field) are a good indicator of problems people have with said technology. They do not search about what they already know and about what works as described. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200121174201.73a36c05%40xmint.
Re: [go-nuts] [long STW] I have a problem with STW, which PauseNs max > 4s
On Wed, 11 Dec 2019 00:20:16 -0800 (PST) kcn wrote: > go version = 1.9 This Go version is no longer supported. That's why you did not get other answers yet. > I know golang's STW is very efficient，but I don't know what happens about > this, > when I restart the program, everything returns normal. Go runtime garbage collector has improved much since 1.9. and way too many changes went to the runtime since 1.9 to have someone investigate further. > when I restart the program, everything returns normal. A good news, likely. Get cron do that restart for you :) The second and more sane solution is to recompile with current Go version and raise issue if your core problem would persist. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191212093016.6236e107%40zuzia.
[go-nuts] [ANN] godoc: allow for lists, links, and rudimentary text styling [proposal].
I would like to announce a "rich godoc syntax" proposal. https://github.com/golang/go/issues/35896 Please do NOT reply to this announce here. The issue/35896 tracker is a proper venue to discuss proposals. Thank you, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191128214351.7bffe258%40zuzia.
Re: [go-nuts] strict type assignability to prevent arbitrary values
On Thu, 7 Nov 2019 02:58:17 -0800 (PST) bsr wrote: > Is there a way I can prevent this behavior. > I am using Status like an enum, and only predefined status values should be > allowed. You cannot statically prevent someone from willfully assigning to a variable of accessible type (eg. a function call parameter). If you're just after sanity check there are many ways. At runtime you can eg. use a map: https://play.golang.org/p/5rwJLFpU3a4 For compile time - you can use stringer tool to generate numerical constants mapped to strings. hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191110183714.706237b4%40zuzia.
Re: [go-nuts] Re: Slices, backing array, goroutines, perhaps Considerations for Go2
On Sun, 27 Oct 2019 20:20:07 + roger peppe wrote: > If two things aren't writing concurrently to the same address, what's the > problem? I've got an impression that OP is concerned about arriving at inconsistent/"impossible" shared state (due to poorly thought architecture). 30-20yrs ago this kind of bug have had haunted codebases still using global state, where procedure X set some state in S and precomputed S' that was then being used by procedure Z; but in meantime the S, and only S, had got modified (by some procedure Y in the middle). So, from the pov of Z (that assumed S' ← S) we have had got to an "impossible state". In event-loop driven programs often this happened in seemingly random ways. @Gert, This indeed can easily can be "achieved" in a single threading Go code that uses slices (pointers) to the shared state. It was, it is, and it always will be a programmer's error. More, no known to me code analysis tool could comprehend changes to your shared state in full and then flag only the wrongs. An AI capable of that would also be capable of replacing us at our desks ;) Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191028112516.750f1649%40zuzia.
Re: [go-nuts] Extending an array 'The right way'. Guidence needed!
On Tue, 15 Oct 2019 03:16:35 -0700 (PDT) Stuart Davies wrote: Uh, the important citation got deleted somehow: [...] https://golang.org/ref/spec#Appending_and_copying_slices "If the capacity of s is not large enough to fit the additional values, append allocates a new, sufficiently large underlying array that fits both the existing slice elements and the additional values. Otherwise, append re-uses the underlying array. " Correct use of append is to reassign the target array: target = append(target, toappend) then append will take care of resizing/copying for you. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191015134349.6148fb74%40zuzia.
Re: [go-nuts] Extending an array 'The right way'. Guidence needed!
On Tue, 15 Oct 2019 03:16:35 -0700 (PDT) Stuart Davies wrote: > Hi > > I have a slice backed by an array. > > My understanding is that I can extend the slice (append) up to the > capacity of the array. Its good understanding. > Append fails when the backing array indexes are exceeded. "exceeded" means "over the capacity" > I know there must be an array copy function that will do this more > efficiently but I failed to find it! It is a built-in function and is aptly named "copy": https://golang.org/ref/spec#Appending_and_copying_slices > Please help. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191015133246.111bd096%40zuzia.
Re: [go-nuts] Re: An old problem: lack of priority select cases
On Fri, 4 Oct 2019 15:15:30 -0700 (PDT) T L wrote: > > If your out <-v must be dependent of ctx.Done not being ready you > > must resolve this dependency by other means. Eg. by selecting for it > > in separate select before. > > > It is not a must. It just tries to select ctx.Done if possible. > In fact, if the two evens are independent with each other, > there is no way to absolutely ensure the must. If it is not a must, then introducing an order at best is void (of no use) at worst it makes sure for a race condition by its very presence. For coming together events A and B that are independent: - proceeding them in either order A, B or in order B, A should result in the same final state as if they came in said order. Hence select's case ordering is unnecessary. - otherwise (that final state depends on order) we have a dependency and the select switch, by language design, is not the right construct to write this dependency down. FYI, AFAIR: the "1+default" select case is optimized by the compiler, so now it is more efficient to have "priority" written explicit than to have more than one case in a select (what turns on all the heavy machinery of a full select block). Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191005122810.11063fab%40zuzia.
Re: [go-nuts] Re: An old problem: lack of priority select cases
On Fri, 4 Oct 2019 15:42:35 -0700 Kurtis Rader wrote: > > On Fri, Oct 4, 2019 at 3:15 PM T L wrote: > > [...] > Please, drop it. You don't know what you're talking about. I've been amazed > at how patient everyone has been. We need this kind of discussions and arguments. It prepares us to deal with problems of understanding that junior programmers may have, or even to deal with our own skewed understandings of the foggy corners of the language. > > [...] > I think it's time to be more blunt in pointing out you don't understand > concurrency and independent events. Even if mr Tapir really does not, he for sure would not be alone, so we all benefit from his questioning the Emperor's wear. So please don't be rude to him. TC, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191005104629.11371341%40zuzia.
Re: [go-nuts] Re: An old problem: lack of priority select cases
On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) T L wrote: > One priority-order select block is not only cleaner than two random-order > select blocks, but also more efficient. It is neither. 1. It is not cleaner, because you would need to somehow denote priorities. If you think now about "in written order", you should think of the most frequent cases that you do not want to have all five, ten, twenty cases be serviced on order. Not to mention that down the road someone might introduce an unnoticeable bug for pure aesthetic reasons. 2. It is not more efficient, it is less efficient because every select operation would need at least a "priority comparison" op, or - in general case - a sort op, because not only two channels can be ready, it may happen that all of them will. This would have to run for every select then, unless introduced by a "select_with_priorities" keyword. 3. Others tried to no avail, I will too in other words: The select switch is deliberately randomized because language creators envisioned that otherwise someone would be "smart" and will use ordering to impose a **dependency** where it should not be made. Channel operations serviced by select are treated as sourced from **independent** events. Period. If your out <-v must be dependent of ctx.Done not being ready you must resolve this dependency by other means. Eg. by selecting for it in separate select before. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191004233941.0b5c516e%40zuzia.
Re: [go-nuts] CreateFile hello.go: The system cannot find the file specified
On Fri, 20 Sep 2019 02:51:04 -0700 (PDT) Kapil Dev wrote: > following are env details Do not post images of text to this list ever again, please. Some people that read go-nuts have low vision and use screen readers. Samples of code should be posted to https://play.golang.org and shared via link. > Kapil Dev -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190922110451.6aa8e1b0%40zuzia.
Re: [go-nuts] Re: Running golang compiled binary on QNX
On Wed, 11 Sep 2019 05:45:18 -0700 (PDT) scab...@gmail.com wrote: > Right. I could have my question better. > The real question is whether there is any hope of QNX support in go. If you work for a company that pays a few million bucks yearly for qnx licenses AFAIK BlackBerry will be happy to do the Go port for your employer. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190912191800.04ec51f9%40zuzia.
Re: [go-nuts] Re: What is the reason behind time.Parse using a reference time?
On Thu, 15 Aug 2019 07:52:24 +0100 Michael Baldry wrote: > It's useful to remember the reference time has a pattern, > but the MST, 12 hour clock and it not being in a common order There is no such thing as "common order" of date/time notation. This notation is a part of the local culture. The Go format pattern happens to be the "most natural" — though just for its birthplace (United States). > (day month, then year later) Thats natural for a big part of Europe and a chunk of Africa. > it is essentially: 01/02 03:04:05PM '06 -0700, that > fact is obscured when parsing in common formats. Hope this helps :) -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190816103949.6a7ff8c6%40zuzia.
Re: [go-nuts] Re: What is the reason behind time.Parse using a reference time?
On Wed, 14 Aug 2019 19:12:40 -0700 (PDT)
sp55aa@gmail.com wrote:
> What is the reason behind time.Parse using a reference time?
The rationale is that every position of the reference time can be
treated as an enum (of int) stating the exact meaning of the field:
01/02 03:04:05PM '06 -0700
1 2 3 4 5 6 7 : M D h m s year zone/offset
You then use these enums to tell the parser where in *your* date/time
format to parse these fields are. These are accompanied by words of
"Mon"/"Monday" "Jan"/"January" to show parser that format use names.
Eg. you may need the "06/01" ("year's last two digit / month") format to
extract dates off some monthly financial reports.
In other place you will use "__2/06" ("day-of-year/year") to parse
daily sales reports.
Read https://golang.org/pkg/time/#pkg-constants till it clicks in :)
This is as simple and brilliant as many other things in Go.
Just the docs are somewhat terse.
> I think "2006-01-02 15:04" is a good idea, but have bad practice.
> you cannot understand this code directly. then it is easy to write wrong
> code like: time.Parse("1970-01-01 00:00", "2011-01-19 22:15")
With format placeholders other languages use code is less readable
until you memorize all of mnemonics. [ man date, look what %_I does mean].
In Go you need only to remember that month is a first member of
"month, day, hour, minutes, seconds, year, zone" sequence and you
can read/understand any of hundreds being in use date formats.
Hope this helps,
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20190815144747.65f16214%40zuzia.
Re: [go-nuts] Wrapper package for dialog (and Xdialog)?
On Sun, 11 Aug 2019 06:17:53 -0700 (PDT) Tong Sun wrote: > I know there are several ncurses based wrapper packages (like goncurses), > but are there any wrapper packages out there dialog (and Xdialog), or > something similar? The goncurses is still too low-level for my > simple dialog-base requirement/use. You can try to embed tcl/tk, the standard unix way for doing dialog with x-user. [recent] https://github.com/visualfc/atk [ooold] https://github.com/nsf/gothic Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190812145206.646bbeb6%40zuzia.
Re: [go-nuts] Re: How to mock functions in Go ?
On Sat, 3 Aug 2019 22:35:44 -0700 (PDT)
Andrey Tcherepanov wrote:
> what if you need only a subpart of the package to be mocked ?
import smthorig "smth"
type smthT struct{
//functions
f1 func signature
f2 func signature
}
// functions
func mof1 (in...) (out...) { /* here your mock goes */ }
func mof2 (in...) (out...) { return smthorig(in...) }
var smth = smthT{ f1: mof1, f2: mof2 }
// methods
func (o smth) m1 (in...) (out...) { /* here your mock goes */ }
func (o smth) m2 (in...) (out...) { return smthorig(in...) }
Types are aliased
interfaces should be used from smthorig intact
Beware of packages that have init and keep state.
Hope this helps.
--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/20190804140657.4af7792a%40zuzia.
Re: [go-nuts] time.Format vs. fmt.Sprintf
On Tue, 23 Jul 2019 18:45:14 -0500 Robert Engels wrote: > Funny. Did you remember it or just pay close attention to these things? I personally did not remember nor I paid close attention, I just read it. > >>> On Thursday, April 5, 2012 at 3:24:09 PM UTC-4, Russ Cox wrote: > >>> April 5, 2012 (for ascii impaired webpages) April 5, 2012 (for insane mail clients that cut all interleaved citations) -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190724175517.64fc4a1f%40zuzia.
Re: [go-nuts] Does reducing capacity of a slice return memory?
On Fri, 19 Jul 2019 18:47:36 -0700 (PDT) Andrey Tcherepanov wrote: > knows that there is only one reference to the remaining part, > and that part is "small" This "is it small"? is a check that would be performed for all, while only tiny percent would benefit off it. >>> I understand that it is very easy on application level... And thats why it belongs there, IMO :) >>> if programmer even thought about it. She certainly should, because only she does know meaning of "big" and "small" in context. > A. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190720230836.5bc499b0%40zuzia.
Re: [go-nuts] Re: About the Google logo on the new Go website
On Tue, 16 Jul 2019 23:06:41 -0700 Michael Jones wrote: > In regards to Oracle, I was delighted when they released under GPL > and remain delighted that they pay Oracle employees to enhance it > and share their work. Excuse me?! 1. VirtualBox was opensourced under GPL by its real creators, the Innotek GmbH. 2. Even before that, VirtualBox was available under so called PUEL license first to developers then also to SMEs -- i.e. to everyone that made install by him or herself. 3. VirtualBox was acquired by the Sun Corporation in 2008 and Sun had put quite a money to make VBox creation/administration GUI tools, including working metal->virtual converters. 4. Then Oracle bought Sun. Many small users expected that PUEL licensing -- as a part of Innotek acquisition deal -- will stay. It stood for the short period Oracle lawyers needed to null PUEL obligations Oracle inherited from Sun. Since then (v5.1 iirc) Virtualbox can be used for free only by pupils and hobbyists. (You're out of PUEL right at the first $1 earned on IT-related work, whether Virtualbox was involved or not). > The name 'Oracle' on that page does not discomfort me Me it disgusts a lot. P.S. This is really OT for the go-nuts list, but the Oracle's "alternative facts" that are spread in many media outlets need correction. I do not blame Michael Jones for falling a prey to that - he's within a legion. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190717114553.5c6793b7%40zuzia. For more options, visit https://groups.google.com/d/optout.
