[go-nuts] Code markup in golang-nuts

[Amnon]

Slightly off topic.
But is there any way to enhance google groups so that it will support 
Markdown?
Or at least provides a simple way to post formatted code without the 
indentation being destroyed?

People often want post code snippets on this group.
And I have yet to find an easy way to do this.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cbd83ea9-53f1-4041-8fbe-1333fdf60ce0n%40googlegroups.com.

[go-nuts] Re: [ANN] star-tex: a Go engine for TeX

[Patrick]

Hi Sebastien,

a few years ago I started with dvitype

https://github.com/speedata/gotex

Patrick

Sebastien Binet schrieb am Dienstag, 16. Februar 2021 um 15:23:41 UTC+1:

> hi there,
>
> I'd like to introduce star-tex[1], a (Work In Progress) TeX engine.
>
> it wraps the output of the official texlive tex.w WEB file (ie: C/C++
> files) as a CGo package.
>
> the idea is to replace in an adiabatical fashion the C bits with their
> Go equivalent.
>
> there's already code that can correctly decode TeX Font metrics files.
>
> $> go get git.sr.ht/~sbinet/star-tex/cmd/star-tex
>
> $> star-tex ./testdata/hello.tex out.div
> $> dvipdf out.dvi
> $> pdf out.pdf
>
>
> PR and patches welcomed :)
>
> -s
>
> [1]: https://sr.ht/~sbinet/star-tex
>
>

-- 
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/53f9b35a-eedd-401c-9b7d-8d1bf7dd9977n%40googlegroups.com.

[go-nuts] Re: How do you test an unpublished module?

['Carla Pfaff' via golang-nuts]

The modules documentation has a section on this: "Developing and testing 
against unpublished module code"
https://golang.org/doc/modules/managing-dependencies#tmp_9

On Saturday, 20 February 2021 at 13:10:38 UTC+1 pkle...@xs4all.nl wrote:

> Is there a way to tell go.mod that it should use local files instead
> of a repository, just for the development phase?
>
>

-- 
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/d24ecd3b-72f7-4313-9bd4-8ffacd42e643n%40googlegroups.com.

[go-nuts] [generics] type switches

[thepud...@gmail.com]

Hello fellow gophers,

Ian announced the intention to update how type switches work in the 
generics proposal in a golang-nuts thread from this August:

 https://groups.google.com/g/golang-nuts/c/iAD0NBz3DYw

It included this from Ian (which is a snippet of his item #4 from his first 
post there):


--
In a type switch on a type parameter with a type list, every case 
listed must be a type that appears in the type list (“default” is also 
permitted, of course). A case will be chosen if it is the type matched 
by the type argument, although as discussed above it may not be the 
exact 
type argument: it may be the underlying type of the type argument. To 
make 
that rule very clear, type switches will not be permitted for type 
parameters that do not have type lists.

--

There was a follow-on discussion in that thread on the desired type switch 
behavior, including gophers like Rog Peppe and Jimmy Frasche commenting on 
what they were hoping this meant.

I think the conclusion of that conversation might have been that adjustment 
in type switch behavior suggested by Ian was not adopted as part of the 
current proposal... but I'm not 100% sure, and wanted to check if that is 
indeed the case (vs. maybe it was adopted, and perhaps I am just missing 
how it works in the current go2go prototype, or maybe it is still planned 
to be adopted but maybe the proposal and/or prototype haven't been updated 
yet).

The most definitive comment from Ian as part of that conversation might 
have been:


--
https://groups.google.com/g/golang-nuts/c/iAD0NBz3DYw/m/5KceLsiLBAAJ

--

Given a type parameter, there are two interesting pieces of
information. One is what the actual type argument is; we can already
determine that by writing code like "var x T; switch
(interface{})(x).(type) { ... }". The other is which type in the type
list was matched by the type argument. The latter is the purpose of
the type switch suggested here. Without something like that type
switch, there is no straightforward way for a generic function to
determine which type in a type list is matched by a type argument.

See also 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type

I'm not at all wedded to this. We can continue to omit it. It just
seems like adding a capability that does not otherwise exist.

--

The current draft seems to hold out the following as a future option:


--

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type

--
One way to handle this would be to permit type switches on the type T, 
with the 
proviso that the type T would always match a type defined in the 
constraint. This 
kind of type switch would only be permitted if the constraint lists 
explicit types, 
and only types listed in the constraint would be permitted as cases.

--

In any event, I am curious about the latest thinking and/or latest status. 
If this has been discussed at length elsewhere since that August thread, I 
would be happy for a pointer if anyone has one.

Thanks, and sorry if the answer is I am just confused ;-)

Best regards,
thepudds

-- 
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/dbdc0e64-b41d-4c69-9218-5972dc3b21a3n%40googlegroups.com.

Re: [go-nuts] where is an online version of older versions like 1.8 1.6 golang pkg doc ?

[Garian Nobinger]

Thank you derek, your references just saved me some headache.


On Sunday, January 21, 2018 at 11:11:39 AM UTC-6 derek wrote:

> On Fri, Jan 19, 2018 at 10:07 AM, Ian Lance Taylor  
> wrote:
> > Sounds like a good approach. Or I'm also open to someone writing the
> > necessary code for golang.org.
>
> I just started this approach simply serving static html files:
>
> https://golangdoc.github.io/pkg/1.10beta2/
> https://golangdoc.github.io/pkg/1.8.5/
> https://golangdoc.github.io/pkg/1.8/
> https://golangdoc.github.io/pkg/1.6/
>
> Only the doc under pkg/ works so far, not any src/ code yet (some
> generated html for src/ are too big, I'm not sure how to handle
> efficiently),
> for my own use case, the pkg/ doc is most often looked up as reference;
>
> On Friday, January 19, 2018 at 3:54:34 PM UTC-8, Florin Pățan wrote:
> > I think this would further encourage people to be lazy and not upgrade 
> to newer Go versions.
>
> Development within corporate has a nature of being conservative; you
> can't simply force everyone to upgrade
>
> As the Golang grows to age 10+; at some point, you will have to handle
> the historic versions; I still hope this can be handled by official
> golang.org/
>
> At least so far, I can simply share by a single link to friends of
> these links, and these are permanent links, public to Google search
>
> https://golangdoc.github.io/pkg/1.10beta2/strings/index.html#Builder
> (the one added in Go1.10)
> https://golangdoc.github.io/pkg/1.10beta2/sync.html#Map
> (this one added in Go1.9)
> https://golangdoc.github.io/pkg/1.8/sort/index.html#Slice
> (this one added in Go1.8)
>
>
> I am not subscribing the whole golang-nuts@ ; so please copy me if you
> want me to report issues to me.
>

-- 
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/261ace37-c3ca-403b-bac5-0c4289b3d2e7n%40googlegroups.com.

Re: [go-nuts] Error handling

[Michael MacInnis]

I don't believe anyone is talking about not handling errors. There are 
functions that perform a sequence of actions and need to go no further when 
an error is encountered. An example of this type of function is presented 
in the "Errors are Values" post:

https://blog.golang.org/errors-are-values

Another example is the CopyFile function from "Error Handling - Problem 
Overview":

https://github.com/golang/proposal/blob/master/design/go2draft-error-handling-overview.md

In these cases the caller may be better equipped to know what to do next 
when there is an error.

The "Errors are Values" post gives some examples of using the language to 
simplify error handling. The check/handle and try proposals do the same 
thing but by proposing language changes. I don't believe any of them are 
proposing not checking and/or not handling errors.

I can tell you most emphatically that I am not proposing not checking 
and/or not handling errors. 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 
statement." And further if that pattern can be implemented as a 
library/package with acceptable trade offs.

Michael.

On Saturday, February 20, 2021 at 6:54:39 PM UTC-5 ohir wrote:

> 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/c54ded01-20af-4a92-b10c-f85438ed136bn%40googlegroups.com.

Re: [go-nuts] How do you test an unpublished module?

[Wojciech S. Czarnecki]

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

[Wojciech S. Czarnecki]

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] Error handling

[Michael MacInnis]

Neat. What you and I are doing is very similar. Particularly how the 
handler is "bound" to the error and checks to make sure that the error is 
non-nil before attempting to recover.

The differences I see in our approaches are as follows:


I support wrapping an error or performing some arbitrary action. This 
wouldn't be difficult for you to add - just add a func() parameter to 
RecoverOn that is invoked when *err != nil. If you did that then we would 
both support performing actions whether an early return was triggered by 
check/ro.ReturnOn or a regular return with err set (assuming named return 
values).


I bind the check function (what you call ro.ReturnOn) to the error so that 
it can set that when passed a non-nil error. This allows check to be used 
directly, for example, on a function that only returns an error:

check(functionThatReturnsAnError())

Instead of having to do:

err = functionThatReturnsAnError()
ro.ReturnOn(err)

Binding the check and done functions means returning them both from a call 
to handle.Error. This adds one more line of code (defer done()) but means 
that check doesn't exist without this step and given that Go complains 
about unused variables it takes some work to forget to do something with 
done. My hope is that this significantly reduces the risk of an unhandled 
panic. (It's still possible to just call done and forget to defer it or 
name done _ so that the compiler won't complain, etc., etc.) As an added 
bonus people can call this pair of functions whatever they want 
(check/done, try/handle, ReturnOn/RecoverOn...). When I first posted I 
thought it would be neat to do:

check, handle := handle.Error // ...
so that the shadowing would make it impossible to call handle.Error again. 
But then I added Chain.

(It would be nice to get the handle.Errorf case down to one line but I 
haven't figured out a way to do that. Maybe something with how arguments to 
deferred function are evaluated but the function call itself isn't...)


In check I wrap the error in an unexported type:

type failure struct {
error
}

If this manages to slip by the idea is that it should be reported as an 
"unhandled error" plus the text of the actual error. It is the 
responsibility of done to unwrap the error and perform any actions on that. 
I'm paranoid about invoking recover, only invoke it when the error is the 
unexported failure type and even then check to make sure that the recovered 
value matches the error value. It is possible to always recover and then if 
we recover something we weren't supposed to, re-panic, but then we lose all 
the context for the original panic.


Looking back at the error handling problem outline I realized that I did 
not have the ability to add additional error handling actions. I added 
Chain a few days after my original post.


Michael.

On Saturday, February 20, 2021 at 4:21:10 PM UTC-5 michael...@gmail.com 
wrote:

> 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.  
>
> https://github.com/Michael-F-Ellis/ro
>
> The code is almost trivial. It consists of two small functions, 
> ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:
>
> import "github.com/Michael-F-Ellis/ro" 
>
> func myfunc() (err error) { 
> defer ro.RecoverOn() 
>
> err = SomeFunctionCall() 
> ro.ReturnOn(err)
>
> // Do more stuff 
> // ... 
> return 
> }
>
> ReturnOn panics if err is not nil.
>
> RecoverOn recovers from the panic raised by ReturnOn and the function 
> exits with whatever error value would have been returned 
> normally. RecoverOn does not interfere with panics arising outside 
> of ReturnOn.
>
> Benefits and tradeoffs (coding discipline, debugging, performance) are 
> discussed in the README.
>
> Feedback welcomed either in this thread or in the repo issues.
>

-- 
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/87c73aa0-2ea2-4125-8cc9-3fe7972a4db9n%40googlegroups.com.

Re: [go-nuts] Error handling

[Robert Engels]

Some developers build sheds others build skyscrapers. Exceptions let you build 
skyscrapers - but not everyone needs a skyscraper. 

I’ve use both methods extensively in my career - well written exception code is 
far easier to write and maintain for more complex systems.

> On Feb 20, 2021, at 2:31 PM, Matthew Holiday  
> wrote:
> 
> 
> I'm referring to errors found in the function (i.e., by calling other 
> functions). It's the responsibility of the callers of a function to handle 
> the errors it returns, and not the function itself. How can one function 
> claim responsibility for the error handling strategy of all programs using it?
> 
> Yes, I suppose in some sense exceptions guarantee all errors are handled 
> somewhere. Unfortunately, what I've seen of exception handling over the years 
> is that it's often "log the stack trace and keep moving", which isn't all 
> that useful, and tends to cover up real bugs. A better approach would be not 
> to catch exceptions at all, and let them crash the program (which is what 
> Go's panic will do); this ensures the bugs are really handled by removing 
> them from the program.
> 
> [And given this type of exception "handling" it's not much value to the 
> author of a single function to know that the errors will all be "handled" 
> somewhere.]
> 
> Unfortunately, exception handling languages tend to put all types of errors, 
> normal and abnormal *, into the same basket. Which means you can't do 
> sensible error handling for, e.g., JSON that doesn't decode, while allowing 
> the program to crash when there's a logic bug. (For non-safety critical 
> software, a crash failure is typically the safest way to fail. 
> Safety-critical software, on the other hand, avoids exception handling like 
> the plague.)
> 
> * A normal error is some behavior that can reasonably be expected, such as 
> "file not found" or "no route to host", etc. Abnormal errors are logic bugs 
> in the program.
> 
> An aside:
> 
> Assuming you had a cyclomatic complexity calculator that took exceptions into 
> consideration, such that exceptions passing through a function counted as a 
> branch, what kind of numbers would you get? Probably pretty awful, given just 
> about any line of code would be capable of throwing an exception. But 
> exceptions typically aren't counted, so that functions are thought to be far 
> less complex than they really are in the presence of exceptions.
> 
> Invisible (magic) return paths through a function go against the notion of 
> "the code does what it says on the page".
> 
>> On Sat, Feb 20, 2021 at 1:11 PM Robert Engels  wrote:
>> Can you clarify what you mean mean by “the code does exactly what it shows 
>> on the page”? How do you know by looking at the code, or even compiling the 
>> code, that all possible errors returned by a function are handled? That to 
>> me is biggest difficult in reading (or using) others Go code. Exceptions 
>> (well written) handle this by declaring all possible error (or categories) 
>> thrown by the method. 
>> 
>> This seems a real problem with long term maintenance of Go code. 
>> 
 On Feb 20, 2021, at 1:39 PM, Matthew Holiday  
 wrote:
 
>>> 
>>> Roger beat me to it.
>>> 
>>> But allow me to rephrase,
>>> 
>>> "The users of Go for a long time have resisted any changes to its simple, 
>>> clear method of error handling despite it being a major concern of folks 
>>> who don't use Go much." *
>>> 
>>> * I'm referring to the original survey, which was worded along the lines of 
>>> "what keeps you from adopting Go?"
>>> (implying that the responders are those who haven't adopted Go)
>>> 
>>> Any type of error handling that creates invisible returns in a function is 
>>> a bad idea IMNSHO (an opinion backed up by various researches into the 
>>> complexity of exception handling). Speaking for myself, I'd like to retain 
>>> that quality of Go whereby "the code does exactly what it says on the page."
>>> 
>>> 
 On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
 
 
> On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:
> Rust lang, very early in its evolution, saw the need to create its 
> operator '?'  to more efficiently manage error handling. But the 
> guardians of Go lang have resisted any changes to its clumsy method of 
> error handling despite it being a major concern of Go users for a very 
> long time. 
 
 
 Actually the "guardians of Go" (by which I guess you mean the Go team at 
 Google) tried quite hard recently to propose an improved way of handling 
 errors, but it was resisted by "Go users". So what you're saying is just 
 not true, I'm afraid.
 
> 
> 
>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>> 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 

Re: [go-nuts] Error handling

[Robert Engels]

I consider checked vs unchecked exceptions “well written” or even valid code. 
Checked exceptions are similar to Gos error return except more/easier/better? 
compile and coding time validation. Unchecked exceptions are similar to panic 
recover except you have more information. 

There is no difference between checked exceptions and Go’s error return in 
terms of responsibility - but exceptions are more easily enforced. 

When it comes to unchecked exceptions a lot depends on the use case. For 
instance, the consider an illegal state exception. Clearly a programming error, 
but how it is handled at higher levels depends... maybe roll back the current 
transaction and report an error to the caller, maybe crash the server? It all 
depends on the context , risk, capabilities - easier for higher layer to make 
this call than a low level function. Coupled with RAI you can create very 
robust and reliable systems. 

> On Feb 20, 2021, at 2:30 PM, Ian Lance Taylor  wrote:
> 
> On Sat, Feb 20, 2021 at 12:11 PM Robert Engels  wrote:
>> 
>> Can you clarify what you mean mean by “the code does exactly what it shows 
>> on the page”? How do you know by looking at the code, or even compiling the 
>> code, that all possible errors returned by a function are handled? That to 
>> me is biggest difficult in reading (or using) others Go code. Exceptions 
>> (well written) handle this by declaring all possible error (or categories) 
>> thrown by the method.
>> 
>> This seems a real problem with long term maintenance of Go code.
> 
> When you say that exceptions means declaring all possible errors
> thrown by the method, it seems to me that you are talking about
> checked exceptions.  There is pretty good evidence that real programs
> in practice do not list all possible error categories, even though
> ideally they should.  Instead, in practice, they fall back to
> unchecked exceptions.
> 
> So I think that your contrast to Go is an ideal that experience has
> shown is very difficult to achieve.  It's not an approach that leads
> to better long term maintenance in practice, even if it should in an
> ideal world.
> 
> (Incidentally, to answer the question in your first sentence directly,
> Go code does indeed do exactly what it shows on the page.  You are
> challenging that not by saying that it does something else, but by
> saying that that is not enough.)
> 
> Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D5D376CE-34D2-4575-94F4-CF899545F368%40ix.netcom.com.

Re: [go-nuts] Error handling

[Michael Ellis]

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.  

https://github.com/Michael-F-Ellis/ro

The code is almost trivial. It consists of two small functions, 
ro.RecoverOn( err *error) and ro.ReturnOn(err error), used as follows:

import "github.com/Michael-F-Ellis/ro" 

func myfunc() (err error) { 
defer ro.RecoverOn() 

err = SomeFunctionCall() 
ro.ReturnOn(err)

// Do more stuff 
// ... 
return 
}

ReturnOn panics if err is not nil.

RecoverOn recovers from the panic raised by ReturnOn and the function exits 
with whatever error value would have been returned normally. RecoverOn does 
not interfere with panics arising outside of ReturnOn.

Benefits and tradeoffs (coding discipline, debugging, performance) are 
discussed in the README.

Feedback welcomed either in this thread or in the repo issues.

On Saturday, February 20, 2021 at 3:31:22 PM UTC-5 matthew...@nytimes.com 
wrote:

> I'm referring to errors found in the function (i.e., by calling 
> other functions). It's the responsibility of the callers of a function to 
> handle the errors it returns, and not the function itself. How can one 
> function claim responsibility for the error handling strategy of all 
> programs using it?
>
> Yes, I suppose in some sense exceptions guarantee all errors are handled 
> somewhere. Unfortunately, what I've seen of exception handling over the 
> years is that it's often "log the stack trace and keep moving", which isn't 
> all that useful, and tends to cover up real bugs. A better approach would 
> be not to catch exceptions at all, and let them crash the program (which is 
> what Go's panic will do); this ensures the bugs are really handled by 
> removing them from the program.
>
> [And given this type of exception "handling" it's not much value to the 
> author of a single function to know that the errors will all be "handled" 
> somewhere.]
>
> Unfortunately, exception handling languages tend to put all types of 
> errors, normal and abnormal *, into the same basket. Which means you can't 
> do sensible error handling for, e.g., JSON that doesn't decode, while 
> allowing the program to crash when there's a logic bug. (For non-safety 
> critical software, a crash failure is typically the safest way to fail. 
> Safety-critical software, on the other hand, avoids exception handling like 
> the plague.)
>
> * A normal error is some behavior that can reasonably be expected, such as 
> "file not found" or "no route to host", etc. Abnormal errors are logic bugs 
> in the program.
>
> An aside:
>
> Assuming you had a cyclomatic complexity calculator that took exceptions 
> into consideration, such that exceptions passing through a function counted 
> as a branch, what kind of numbers would you get? Probably pretty awful, 
> given just about any line of code would be capable of throwing an 
> exception. But exceptions typically aren't counted, so that functions are 
> thought to be far less complex than they really are in the presence of 
> exceptions.
>
> Invisible (magic) return paths through a function go against the notion of 
> "the code does what it says on the page".
>
> On Sat, Feb 20, 2021 at 1:11 PM Robert Engels  
> wrote:
>
>> Can you clarify what you mean mean by “the code does exactly what it 
>> shows on the page”? How do you know by looking at the code, or even 
>> compiling the code, that all possible errors returned by a function are 
>> handled? That to me is biggest difficult in reading (or using) others Go 
>> code. Exceptions (well written) handle this by declaring all possible error 
>> (or categories) thrown by the method. 
>>
>> This seems a real problem with long term maintenance of Go code. 
>>
>> On Feb 20, 2021, at 1:39 PM, Matthew Holiday  
>> wrote:
>>
>> 
>> Roger beat me to it.
>>
>> But allow me to rephrase,
>>
>> "The users of Go for a long time have resisted any changes to its simple, 
>> clear method of error handling despite it being a major concern of folks 
>> who don't use Go much." *
>>
>> * I'm referring to the original survey, which was worded along the lines 
>> of "what keeps you from adopting Go?"
>> (implying that the responders are those who haven't adopted Go)
>>
>> Any type of error handling that creates invisible returns in a function 
>> is a bad idea IMNSHO (an opinion backed up by various researches into the 
>> complexity of exception handling). Speaking for myself, I'd like to retain 
>> that quality of Go whereby "the code does exactly what it says on the page."
>>
>>
>> On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
>>
>>>
>>>
>>> On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:
>>>
 Rust lang, very early in its evolution, saw the need to create its 
 operator '?'  to more efficiently manage error handling. But the guardians 
 of Go lang have resisted any changes to its clumsy 

Re: [go-nuts] Error handling

[Matthew Holiday]

I'm referring to errors found in the function (i.e., by calling
other functions). It's the responsibility of the callers of a function to
handle the errors it returns, and not the function itself. How can one
function claim responsibility for the error handling strategy of all
programs using it?

Yes, I suppose in some sense exceptions guarantee all errors are handled
somewhere. Unfortunately, what I've seen of exception handling over the
years is that it's often "log the stack trace and keep moving", which isn't
all that useful, and tends to cover up real bugs. A better approach would
be not to catch exceptions at all, and let them crash the program (which is
what Go's panic will do); this ensures the bugs are really handled by
removing them from the program.

[And given this type of exception "handling" it's not much value to the
author of a single function to know that the errors will all be "handled"
somewhere.]

Unfortunately, exception handling languages tend to put all types of
errors, normal and abnormal *, into the same basket. Which means you can't
do sensible error handling for, e.g., JSON that doesn't decode, while
allowing the program to crash when there's a logic bug. (For non-safety
critical software, a crash failure is typically the safest way to fail.
Safety-critical software, on the other hand, avoids exception handling like
the plague.)

* A normal error is some behavior that can reasonably be expected, such as
"file not found" or "no route to host", etc. Abnormal errors are logic bugs
in the program.

An aside:

Assuming you had a cyclomatic complexity calculator that took exceptions
into consideration, such that exceptions passing through a function counted
as a branch, what kind of numbers would you get? Probably pretty awful,
given just about any line of code would be capable of throwing an
exception. But exceptions typically aren't counted, so that functions are
thought to be far less complex than they really are in the presence of
exceptions.

Invisible (magic) return paths through a function go against the notion of
"the code does what it says on the page".

On Sat, Feb 20, 2021 at 1:11 PM Robert Engels  wrote:

> Can you clarify what you mean mean by “the code does exactly what it shows
> on the page”? How do you know by looking at the code, or even compiling the
> code, that all possible errors returned by a function are handled? That to
> me is biggest difficult in reading (or using) others Go code. Exceptions
> (well written) handle this by declaring all possible error (or categories)
> thrown by the method.
>
> This seems a real problem with long term maintenance of Go code.
>
> On Feb 20, 2021, at 1:39 PM, Matthew Holiday 
> wrote:
>
> 
> Roger beat me to it.
>
> But allow me to rephrase,
>
> "The users of Go for a long time have resisted any changes to its simple,
> clear method of error handling despite it being a major concern of folks
> who don't use Go much." *
>
> * I'm referring to the original survey, which was worded along the lines
> of "what keeps you from adopting Go?"
> (implying that the responders are those who haven't adopted Go)
>
> Any type of error handling that creates invisible returns in a function is
> a bad idea IMNSHO (an opinion backed up by various researches into the
> complexity of exception handling). Speaking for myself, I'd like to retain
> that quality of Go whereby "the code does exactly what it says on the page."
>
>
> On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
>
>>
>>
>> On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:
>>
>>> Rust lang, very early in its evolution, saw the need to create its
>>> operator '?'  to more efficiently manage error handling. But the guardians
>>> of Go lang have resisted any changes to its clumsy method of error handling
>>> despite it being a major concern of Go users for a very long time.
>>
>>
>> Actually the "guardians of Go" (by which I guess you mean the Go team at
>> Google) tried quite hard recently to propose an improved way of handling
>> errors, but it was resisted by "Go users". So what you're saying is just
>> not true, I'm afraid.
>>
>>
>>>
>>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>>>
 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 

Re: [go-nuts] Error handling

[Ian Lance Taylor]

On Sat, Feb 20, 2021 at 12:11 PM Robert Engels  wrote:
>
> Can you clarify what you mean mean by “the code does exactly what it shows on 
> the page”? How do you know by looking at the code, or even compiling the 
> code, that all possible errors returned by a function are handled? That to me 
> is biggest difficult in reading (or using) others Go code. Exceptions (well 
> written) handle this by declaring all possible error (or categories) thrown 
> by the method.
>
> This seems a real problem with long term maintenance of Go code.

When you say that exceptions means declaring all possible errors
thrown by the method, it seems to me that you are talking about
checked exceptions.  There is pretty good evidence that real programs
in practice do not list all possible error categories, even though
ideally they should.  Instead, in practice, they fall back to
unchecked exceptions.

So I think that your contrast to Go is an ideal that experience has
shown is very difficult to achieve.  It's not an approach that leads
to better long term maintenance in practice, even if it should in an
ideal world.

(Incidentally, to answer the question in your first sentence directly,
Go code does indeed do exactly what it shows on the page.  You are
challenging that not by saying that it does something else, but by
saying that that is not enough.)

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWzfD%2BjjYQKHbu4R%3DxgtSoR_%3Duhp%3DmOEtqwKUvFJp7tWQ%40mail.gmail.com.

Re: [go-nuts] Error handling

[Robert Engels]

Can you clarify what you mean mean by “the code does exactly what it shows on 
the page”? How do you know by looking at the code, or even compiling the code, 
that all possible errors returned by a function are handled? That to me is 
biggest difficult in reading (or using) others Go code. Exceptions (well 
written) handle this by declaring all possible error (or categories) thrown by 
the method. 

This seems a real problem with long term maintenance of Go code. 

> On Feb 20, 2021, at 1:39 PM, Matthew Holiday  
> wrote:
> 
> 
> Roger beat me to it.
> 
> But allow me to rephrase,
> 
> "The users of Go for a long time have resisted any changes to its simple, 
> clear method of error handling despite it being a major concern of folks who 
> don't use Go much." *
> 
> * I'm referring to the original survey, which was worded along the lines of 
> "what keeps you from adopting Go?"
> (implying that the responders are those who haven't adopted Go)
> 
> Any type of error handling that creates invisible returns in a function is a 
> bad idea IMNSHO (an opinion backed up by various researches into the 
> complexity of exception handling). Speaking for myself, I'd like to retain 
> that quality of Go whereby "the code does exactly what it says on the page."
> 
> 
>> On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
>> 
>> 
>>> On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:
>>> Rust lang, very early in its evolution, saw the need to create its operator 
>>> '?'  to more efficiently manage error handling. But the guardians of Go 
>>> lang have resisted any changes to its clumsy method of error handling 
>>> despite it being a major concern of Go users for a very long time. 
>> 
>> 
>> Actually the "guardians of Go" (by which I guess you mean the Go team at 
>> Google) tried quite hard recently to propose an improved way of handling 
>> errors, but it was resisted by "Go users". So what you're saying is just not 
>> true, I'm afraid.
>> 
>>> 
>>> 
 On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com.
>> 
>> -- 
>> 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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com.
> 
> 
> -- 
> Matt Holiday
> Senior Gopher, Marketing Technologies
> 
> 
> 620 Eighth Avenue
> New York, NY 10018
> matthew.holi...@nytimes.com
> -- 
> 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/CAGSa1C%3DyS48YXZ95ut_LaEiBU2MKCKF5pERgkW5q7%2BHVFv4Stw%40mail.gmail.com.

-- 
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/8A49E2C4-28FC-4777-8AD8-4FC4E6E2E347%40ix.netcom.com.

Re: [go-nuts] Error handling

[Matthew Holiday]

Roger beat me to it.

But allow me to rephrase,

"The users of Go for a long time have resisted any changes to its simple,
clear method of error handling despite it being a major concern of folks
who don't use Go much." *

* I'm referring to the original survey, which was worded along the lines of
"what keeps you from adopting Go?"
(implying that the responders are those who haven't adopted Go)

Any type of error handling that creates invisible returns in a function is
a bad idea IMNSHO (an opinion backed up by various researches into the
complexity of exception handling). Speaking for myself, I'd like to retain
that quality of Go whereby "the code does exactly what it says on the page."


On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:

>
>
> On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:
>
>> Rust lang, very early in its evolution, saw the need to create its
>> operator '?'  to more efficiently manage error handling. But the guardians
>> of Go lang have resisted any changes to its clumsy method of error handling
>> despite it being a major concern of Go users for a very long time.
>
>
> Actually the "guardians of Go" (by which I guess you mean the Go team at
> Google) tried quite hard recently to propose an improved way of handling
> errors, but it was resisted by "Go users". So what you're saying is just
> not true, I'm afraid.
>
>
>>
>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>>
>>> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com
> 
> .
>


-- 
*Matt Holiday*
Senior Gopher, Marketing Technologies

620 Eighth Avenue

New York, NY 10018

matthew.holi...@nytimes.com

-- 
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/CAGSa1C%3DyS48YXZ95ut_LaEiBU2MKCKF5pERgkW5q7%2BHVFv4Stw%40mail.gmail.com.

Re: [go-nuts] How to use atomic_int in cgo?

[Ian Lance Taylor]

On Sat, Feb 20, 2021 at 8:34 AM changkun  wrote:
>
> Dear Ian, thanks for the inspiration and sorry for the late response. I just 
> got a chance to test your suggestion.
> But, it turns out that the wrapping struct can cause the following error:
>
> panic: runtime error: cgo argument has Go pointer to Go pointer
>
> If my understanding of Cgo constraints correctly, the panic is to prevent a 
> potential error when GC moves the Go pointer,
> although we don't manipulate the Go pointer (to the channel) from the C side.
>
> How could we avoid this?

Oh, sorry.  There are lots of ways to go, depending on the details.
The easiest is to store the channel in a global variable on the Go
side, though of course then only one goroutine can use this system at
a time.  Or you can build a map on the Go side that maps integers to
channel, then pass the integer to C which will pass it back to Go and
the Go side will look in the map.

Ian

> On Monday, February 15, 2021 at 9:51:03 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Mon, Feb 15, 2021 at 12:39 PM changkun  wrote:
>> >
>> > Thanks for the hint, but I have some follow-up questions:
>> >
>> >>
>> >> Even if there were a way to do this, an atomic variable is not a good
>> >> synchronization mechanism, because the other side has to poll the
>> >> variable.
>> >
>> > Indeed, it the other side will be a spin loop to poll the atomic variable, 
>> > which ...
>> >
>> >
>> >>
>> >> You can do this as a last resort, but it doesn't sound like
>> >> you are at a last resort here. I suggest that you have your C
>> >> function call a Go function to write a value on a channel.
>> >
>> > seems easy to write than this (?).
>> >
>> > Say a Go function foo is called from the C side, to be able to send to the 
>> > corresponding channel, C must pass that channel to the Go function, which 
>> > brings to the initial question: pass a channel from Go to C, is it 
>> > supported at the moment (?)
>> >
>> > How could a Go function be able to send content to differently allocated 
>> > channels in correspondingly invoked C functions?
>>
>> For example, on the Go side write
>>
>> type chanToUse struct {
>> c chan int
>> }
>>
>> //export MyGoFunction
>> func MyGoFunction(u unsafe.Pointer, val int) {
>> cu = (*chanToUse)(u)
>> cu.c <- val
>> }
>>
>> ch := make(chan int)
>> ...
>> C.MyCFunction(unsafe.Pointer({ch}))
>>
>> and on the C side write
>>
>> void MyCFunction(void *goData) {
>> ...
>> MyGoFunction(goData, 0);
>> }
>>
>> Yes, it's more work. But it's not a good idea to poll an atomic
>> variable in Go. The Go scheduler reacts badly to busy loops.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/19463602-158d-4539-9132-fa6d5b09a8c3n%40googlegroups.com.

-- 
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/CAOyqgcV69t2%3D03roiheR4oLFRT%2B0cv2ZhScWOK8cGscc01yDHg%40mail.gmail.com.

[go-nuts] Re: Differences between go1.16 and go1.15 ?

[TiT8]

Awesome !! 
Thank you.

Il giorno sabato 20 febbraio 2021 alle 19:59:37 UTC+1 DrGo ha scritto:

> Dear Lorenzo,
> Here’s a link to an old but still relevant tutorial on benchmarking Go 
> programs
>
> https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go
>
> Happy benchmarking
>
> On Saturday, February 20, 2021 at 11:19:40 AM UTC-6 TiT8 wrote:
>
>>
>> Thank you Volker.
>>
>> I want to say that I was not trying to benchmark the two version of Go 
>> (two weeks ago I had go1.15.8, now 1.16). At the beginning I was trying to 
>> do some linear algebra with Go as a free “alternative of Matlab”, so I 
>> noted the difference between the exe coming from the two versions.
>> Now I have understand that this is not the way to measure the specific 
>> performance of my issue. I will learn more and also testing.
>>
>> Sorry for your time, but thank you very much for your fast help.
>> Il giorno sabato 20 febbraio 2021 alle 17:31:24 UTC+1 Volker Dobler ha 
>> scritto:
>>
>>> (premature send, sorry)
>>>
>>> 4. Your matrix multiplication is just a few CPU instructions, it is hard
>>> to measure something tiny reliable. So use larger matrixes.
>>> 5. You are benchmarking also how fast you can format and output
>>> the results to stdout. This might or might not be intentional but
>>> probably is just wrong.
>>> 6. There is no point in comparing Go 1.15 and Go 1.16 with 
>>> microbenchmarks
>>> which do not properly measure what you think they do. Your code spends
>>> far too much time in a lot of things. Come up with a _proper_ benchmark
>>> based on testing.B and go test. Make sure this benchmark is stable. Make
>>> sure this benchmarks really benchmarks what you are trying to measure.
>>> Then redo the benchmarks 10 times and compare them doing proper
>>> statistics.
>>>
>>> V.
>>>
>>>
>>> On Saturday, 20 February 2021 at 15:48:32 UTC+1 TiT8 wrote:
>>>
 Hello everyone,
 I'm Lorenzo and I'm not a computer scientist, I have used some "Matlab" 
 and I am new with Go (surprisingly fast, simple and elegant).

 I'm trying to do some basic operation on matrix with the "Gonum" 
 package using vectorization. I was curious about the speed of development 
 and the performance (repeat... surprisingly for me!). So I've tried to do 
 some measures:

 *package main*

 *import (*
 *"fmt"*
 *"time"*

 *"gonum.org/v1/gonum/mat "*
 *)*

 *func main() {*
 *p := mat.NewDense(3, 3, nil)*
 *a := mat.NewDense(3, 3, []float64{*
 *1, 2, 3, 1, 2, 3, 1, 2, 3,*
 *})*

 *start := time.Now()*

 *p.Mul(a, a)  *// element-wise

 *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
 *p.Add(a, a) *

 *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
 *p.MulElem(a, a)*

 *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*

 *fmt.Println(time.Since(start))*
 *}*


 Well... when I run the "go run mat.go" command the result time is about 
 150 microseconds, but when I run "go build" and then execute the binary 
 the 
 result time is about 4 *milli*seconds. This happen when I use go1.16.

 When I use go1.15.8, on the same code, the exe is faster (about 120 
 microseconds) then the "go run mat.go" (about 180 microseconds). One order 
 of magnitude faster than go1.16 exe (and basic Matlab).

 So:

- am I in error with the code (sorry, it's all new for me)? If yes, 
where is my fault?
- if the "benchmark" was correct, why go1.16 build executable is 
slower than go1.15.8 exe and "go run" command?
- Is it my machine's fault or Gonum package or what?
- Do you also have these values?  


 My pc:  HP ELITEBOOK 8560w Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 
 2201 Mhz, 4 Core(s), 8 Logical Processor(s) x64.
 I am on the *Windows Subsystem Linux 2. * 


 *Sorry for my English, I hope you understand my issue, thank you for 
 the attention*







-- 
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/b7b558d9-d14c-4ba7-bcb8-977015e01bfdn%40googlegroups.com.

[go-nuts] Re: Differences between go1.16 and go1.15 ?

[DrGo]

Dear Lorenzo,
Here’s a link to an old but still relevant tutorial on benchmarking Go 
programs

https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go

Happy benchmarking

On Saturday, February 20, 2021 at 11:19:40 AM UTC-6 TiT8 wrote:

>
> Thank you Volker.
>
> I want to say that I was not trying to benchmark the two version of Go 
> (two weeks ago I had go1.15.8, now 1.16). At the beginning I was trying to 
> do some linear algebra with Go as a free “alternative of Matlab”, so I 
> noted the difference between the exe coming from the two versions.
> Now I have understand that this is not the way to measure the specific 
> performance of my issue. I will learn more and also testing.
>
> Sorry for your time, but thank you very much for your fast help.
> Il giorno sabato 20 febbraio 2021 alle 17:31:24 UTC+1 Volker Dobler ha 
> scritto:
>
>> (premature send, sorry)
>>
>> 4. Your matrix multiplication is just a few CPU instructions, it is hard
>> to measure something tiny reliable. So use larger matrixes.
>> 5. You are benchmarking also how fast you can format and output
>> the results to stdout. This might or might not be intentional but
>> probably is just wrong.
>> 6. There is no point in comparing Go 1.15 and Go 1.16 with microbenchmarks
>> which do not properly measure what you think they do. Your code spends
>> far too much time in a lot of things. Come up with a _proper_ benchmark
>> based on testing.B and go test. Make sure this benchmark is stable. Make
>> sure this benchmarks really benchmarks what you are trying to measure.
>> Then redo the benchmarks 10 times and compare them doing proper
>> statistics.
>>
>> V.
>>
>>
>> On Saturday, 20 February 2021 at 15:48:32 UTC+1 TiT8 wrote:
>>
>>> Hello everyone,
>>> I'm Lorenzo and I'm not a computer scientist, I have used some "Matlab" 
>>> and I am new with Go (surprisingly fast, simple and elegant).
>>>
>>> I'm trying to do some basic operation on matrix with the "Gonum" package 
>>> using vectorization. I was curious about the speed of development and the 
>>> performance (repeat... surprisingly for me!). So I've tried to do some 
>>> measures:
>>>
>>> *package main*
>>>
>>> *import (*
>>> *"fmt"*
>>> *"time"*
>>>
>>> *"gonum.org/v1/gonum/mat "*
>>> *)*
>>>
>>> *func main() {*
>>> *p := mat.NewDense(3, 3, nil)*
>>> *a := mat.NewDense(3, 3, []float64{*
>>> *1, 2, 3, 1, 2, 3, 1, 2, 3,*
>>> *})*
>>>
>>> *start := time.Now()*
>>>
>>> *p.Mul(a, a)  *// element-wise
>>> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>>> *p.Add(a, a) *
>>> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>>> *p.MulElem(a, a)*
>>> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>>>
>>> *fmt.Println(time.Since(start))*
>>> *}*
>>>
>>>
>>> Well... when I run the "go run mat.go" command the result time is about 
>>> 150 microseconds, but when I run "go build" and then execute the binary the 
>>> result time is about 4 *milli*seconds. This happen when I use go1.16.
>>>
>>> When I use go1.15.8, on the same code, the exe is faster (about 120 
>>> microseconds) then the "go run mat.go" (about 180 microseconds). One order 
>>> of magnitude faster than go1.16 exe (and basic Matlab).
>>>
>>> So:
>>>
>>>- am I in error with the code (sorry, it's all new for me)? If yes, 
>>>where is my fault?
>>>- if the "benchmark" was correct, why go1.16 build executable is 
>>>slower than go1.15.8 exe and "go run" command?
>>>- Is it my machine's fault or Gonum package or what?
>>>- Do you also have these values?  
>>>
>>>
>>> My pc:  HP ELITEBOOK 8560w Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 
>>> 2201 Mhz, 4 Core(s), 8 Logical Processor(s) x64.
>>> I am on the *Windows Subsystem Linux 2. * 
>>>
>>>
>>> *Sorry for my English, I hope you understand my issue, thank you for the 
>>> attention*
>>>
>>>
>>>
>>>
>>>
>>>

-- 
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/aa1f3f18-abcc-4310-8d03-a7102150708en%40googlegroups.com.

[go-nuts] The composite pattern in GO

[Travis Keep]

I am writing this to see what everyone thinks about a solution I have for 
the composite pattern.

The composite pattern is when 0 or more instances of some interface X can 
act together as a single instance of interface X. For instance you may have 
a Filter interface that filters instances of class Foo like so.

type Filter interface {
IsIncluded(ptr *Foo) bool
}

Filter can follow the composite pattern like so:

type sliceFilter []Filter

func (s sliceFilter) IsIncluded(ptr *Foo) bool {
for _, f := range s {
if !f.IsIncluded(ptr) {
return false
}
}
return true
}

The sliceFilter returns true for a Foo instance if and only if all the 
Filters in the slice filter return true for that Foo instance.

Notice that sliceFilter lets a collection of Filters act as a single Filter 
instance.

You can also have a Filter instance the represents 0 filters like this.

type nilFilter struct {
}

func (n nilFilter) IsIncluded(ptr *Foo) bool {
return true
}

When designing an API around Filters you may include a method called 
Compose that creates a Filter instance out of a bunch of existing Filter 
instances. A naive implementation might look like this

func Compose(filters ...Filter) Filter {
return sliceFilter(filters)
}

While this works, it is not great because if the caller passes a Filter 
slice to Compose and later changes that slice, they unwittingly change the 
returned composite Filter as a side effect.  A better implementation may 
look like this.

func Compose(filter ...Filter) Filter {
result := make(sliceFilter, len(filter))
copy(result, filter)
return result
}

This is better because it makes a defensive copy of the slice. If the 
caller passes a []Filter to Compose and changes it, the returned composite 
Filter works as expected. But this solution isn't optimal either because it 
always allocates and returns a slice no matter what the caller passes to 
it. If the caller passes a single Filter to Compose, Compose should return 
that Filter as is, not a slice. If the caller passes no arguments to 
Compose, Compose should return the nilFilter instance whose IsIncluded 
method always returns true.  If the caller passes a bunch of nil Filters to 
Compose, Compose should return the nil Filter instance.  If the caller 
passes a bunch of nilFilters and one non nil Filter to Compose, Compose 
should return the one non nil Filter.  The only time Compose should 
allocate and return a slice is if it is passed 2 or more non nil Filters.  
If caller passes 2 or more Filters that are slices, Compose should flatten 
those out into a single slice rather than returning a slice of slices.  

common.Join in github.com/keep94/common handles all these edge cases 
automatically.  In addition to a slice type, common.Join requires a nil 
instance which represents 0 of some interface X.

Compose can be written like this

func Compose(filter ...Filter) Filter {
   return common.Join(filter, sliceFilter(nil), nilFilter{}).(Filter)
}

When written like this, Compose will always do the right thing. It will 
only return a newly allocated slice if 2 or more arguments passed to it are 
non nil Filters.  If it gets just one non-nil Filter, it simply returns 
that filter unchanged. If it gets 0 filters, it just returns the 
nilFilter{} instance.

In conclusion, there are some edge cases to consider when implementing the 
composite pattern. common.Join can address all these edge cases.

-- 
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/b859c089-ff6d-4f56-a444-9d477eb8d721n%40googlegroups.com.

Re: [go-nuts] Error handling

[roger peppe]

On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:

> Rust lang, very early in its evolution, saw the need to create its
> operator '?'  to more efficiently manage error handling. But the guardians
> of Go lang have resisted any changes to its clumsy method of error handling
> despite it being a major concern of Go users for a very long time.


Actually the "guardians of Go" (by which I guess you mean the Go team at
Google) tried quite hard recently to propose an improved way of handling
errors, but it was resisted by "Go users". So what you're saying is just
not true, I'm afraid.


>
> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>
>> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com
> 
> .
>

-- 
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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com.

[go-nuts] Re: The GO equiv. to 'tail -f' ?

[Steve Murphy]

Many, many thanks. The hpcloud/tail hit the spot exactly, along with using 
timer.AfterFunc() along with judicious use of .Stop() calls to 
turn on and off
audible alarms. That was just the help I needed! again, Many thanks!

murf 

On Thursday, February 18, 2021 at 12:02:46 PM UTC-7 Amnon wrote:

> What to do depends on the platform.
> But there are quite a few examples around.
>
> https://github.com/hpcloud/tail
> https://github.com/papertrail/go-tail
>
> https://stackoverflow.com/questions/10135738/reading-log-files-as-theyre-updated-in-go
>
> etc...
>
> On Thursday, 18 February 2021 at 18:50:43 UTC Steve Murphy wrote:
>
>> I'm having a hard time finding some tools in GO to follow log files and 
>> make real-time commentary about stuff like alerting about outages now 
>> underway, and  making alerts over things that *should* happen by now but 
>> weren't, and such-like.
>>
>> Any advice? I'm pretty sure I saw an article or two some months ago, but 
>> now nothing shows up in my search engine.
>>
>> Many thanks
>>
>> murf
>>
>> -- 
>>
>> Steve Murphy
>> ParseTree Corporation
>>
>>

-- 
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/780cb75d-8b1c-48b4-bf56-84362aa1cf94n%40googlegroups.com.

[go-nuts] Re: Differences between go1.16 and go1.15 ?

[TiT8]

Thank you Volker.

I want to say that I was not trying to benchmark the two version of Go (two 
weeks ago I had go1.15.8, now 1.16). At the beginning I was trying to do 
some linear algebra with Go as a free “alternative of Matlab”, so I noted 
the difference between the exe coming from the two versions.
Now I have understand that this is not the way to measure the specific 
performance of my issue. I will learn more and also testing.

Sorry for your time, but thank you very much for your fast help.
Il giorno sabato 20 febbraio 2021 alle 17:31:24 UTC+1 Volker Dobler ha 
scritto:

> (premature send, sorry)
>
> 4. Your matrix multiplication is just a few CPU instructions, it is hard
> to measure something tiny reliable. So use larger matrixes.
> 5. You are benchmarking also how fast you can format and output
> the results to stdout. This might or might not be intentional but
> probably is just wrong.
> 6. There is no point in comparing Go 1.15 and Go 1.16 with microbenchmarks
> which do not properly measure what you think they do. Your code spends
> far too much time in a lot of things. Come up with a _proper_ benchmark
> based on testing.B and go test. Make sure this benchmark is stable. Make
> sure this benchmarks really benchmarks what you are trying to measure.
> Then redo the benchmarks 10 times and compare them doing proper
> statistics.
>
> V.
>
>
> On Saturday, 20 February 2021 at 15:48:32 UTC+1 TiT8 wrote:
>
>> Hello everyone,
>> I'm Lorenzo and I'm not a computer scientist, I have used some "Matlab" 
>> and I am new with Go (surprisingly fast, simple and elegant).
>>
>> I'm trying to do some basic operation on matrix with the "Gonum" package 
>> using vectorization. I was curious about the speed of development and the 
>> performance (repeat... surprisingly for me!). So I've tried to do some 
>> measures:
>>
>> *package main*
>>
>> *import (*
>> *"fmt"*
>> *"time"*
>>
>> *"gonum.org/v1/gonum/mat "*
>> *)*
>>
>> *func main() {*
>> *p := mat.NewDense(3, 3, nil)*
>> *a := mat.NewDense(3, 3, []float64{*
>> *1, 2, 3, 1, 2, 3, 1, 2, 3,*
>> *})*
>>
>> *start := time.Now()*
>>
>> *p.Mul(a, a)  *// element-wise
>> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>> *p.Add(a, a) *
>> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>> *p.MulElem(a, a)*
>> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>>
>> *fmt.Println(time.Since(start))*
>> *}*
>>
>>
>> Well... when I run the "go run mat.go" command the result time is about 
>> 150 microseconds, but when I run "go build" and then execute the binary the 
>> result time is about 4 *milli*seconds. This happen when I use go1.16.
>>
>> When I use go1.15.8, on the same code, the exe is faster (about 120 
>> microseconds) then the "go run mat.go" (about 180 microseconds). One order 
>> of magnitude faster than go1.16 exe (and basic Matlab).
>>
>> So:
>>
>>- am I in error with the code (sorry, it's all new for me)? If yes, 
>>where is my fault?
>>- if the "benchmark" was correct, why go1.16 build executable is 
>>slower than go1.15.8 exe and "go run" command?
>>- Is it my machine's fault or Gonum package or what?
>>- Do you also have these values?  
>>
>>
>> My pc:  HP ELITEBOOK 8560w Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 
>> 2201 Mhz, 4 Core(s), 8 Logical Processor(s) x64.
>> I am on the *Windows Subsystem Linux 2. * 
>>
>>
>> *Sorry for my English, I hope you understand my issue, thank you for the 
>> attention*
>>
>>
>>
>>
>>
>>

-- 
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/2cadbc63-1b00-487d-a19f-3772d3ae5487n%40googlegroups.com.

Re: [go-nuts] How to use atomic_int in cgo?

[changkun]

Dear Ian, thanks for the inspiration and sorry for the late response. I 
just got a chance to test your suggestion.
But, it turns out that the wrapping struct can cause the following error:

panic: runtime error: cgo argument has Go pointer to Go pointer

If my understanding of Cgo constraints correctly, the panic is to prevent a 
potential error when GC moves the Go pointer,
although we don't manipulate the Go pointer (to the channel) from the C 
side.

How could we avoid this?

On Monday, February 15, 2021 at 9:51:03 PM UTC+1 Ian Lance Taylor wrote:

> On Mon, Feb 15, 2021 at 12:39 PM changkun  wrote:
> >
> > Thanks for the hint, but I have some follow-up questions:
> >
> >>
> >> Even if there were a way to do this, an atomic variable is not a good
> >> synchronization mechanism, because the other side has to poll the
> >> variable.
> >
> > Indeed, it the other side will be a spin loop to poll the atomic 
> variable, which ...
> >
> >
> >>
> >> You can do this as a last resort, but it doesn't sound like
> >> you are at a last resort here. I suggest that you have your C
> >> function call a Go function to write a value on a channel.
> >
> > seems easy to write than this (?).
> >
> > Say a Go function foo is called from the C side, to be able to send to 
> the corresponding channel, C must pass that channel to the Go function, 
> which brings to the initial question: pass a channel from Go to C, is it 
> supported at the moment (?)
> >
> > How could a Go function be able to send content to differently allocated 
> channels in correspondingly invoked C functions?
>
> For example, on the Go side write
>
> type chanToUse struct {
> c chan int
> }
>
> //export MyGoFunction
> func MyGoFunction(u unsafe.Pointer, val int) {
> cu = (*chanToUse)(u)
> cu.c <- val
> }
>
> ch := make(chan int)
> ...
> C.MyCFunction(unsafe.Pointer({ch}))
>
> and on the C side write
>
> void MyCFunction(void *goData) {
> ...
> MyGoFunction(goData, 0);
> }
>
> Yes, it's more work. But it's not a good idea to poll an atomic
> variable in Go. The Go scheduler reacts badly to busy loops.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/19463602-158d-4539-9132-fa6d5b09a8c3n%40googlegroups.com.

[go-nuts] Re: Differences between go1.16 and go1.15 ?

[Volker Dobler]

(premature send, sorry)

4. Your matrix multiplication is just a few CPU instructions, it is hard
to measure something tiny reliable. So use larger matrixes.
5. You are benchmarking also how fast you can format and output
the results to stdout. This might or might not be intentional but
probably is just wrong.
6. There is no point in comparing Go 1.15 and Go 1.16 with microbenchmarks
which do not properly measure what you think they do. Your code spends
far too much time in a lot of things. Come up with a _proper_ benchmark
based on testing.B and go test. Make sure this benchmark is stable. Make
sure this benchmarks really benchmarks what you are trying to measure.
Then redo the benchmarks 10 times and compare them doing proper
statistics.

V.


On Saturday, 20 February 2021 at 15:48:32 UTC+1 TiT8 wrote:

> Hello everyone,
> I'm Lorenzo and I'm not a computer scientist, I have used some "Matlab" 
> and I am new with Go (surprisingly fast, simple and elegant).
>
> I'm trying to do some basic operation on matrix with the "Gonum" package 
> using vectorization. I was curious about the speed of development and the 
> performance (repeat... surprisingly for me!). So I've tried to do some 
> measures:
>
> *package main*
>
> *import (*
> *"fmt"*
> *"time"*
>
> *"gonum.org/v1/gonum/mat "*
> *)*
>
> *func main() {*
> *p := mat.NewDense(3, 3, nil)*
> *a := mat.NewDense(3, 3, []float64{*
> *1, 2, 3, 1, 2, 3, 1, 2, 3,*
> *})*
>
> *start := time.Now()*
>
> *p.Mul(a, a)  *// element-wise
> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
> *p.Add(a, a) *
> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
> *p.MulElem(a, a)*
> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>
> *fmt.Println(time.Since(start))*
> *}*
>
>
> Well... when I run the "go run mat.go" command the result time is about 
> 150 microseconds, but when I run "go build" and then execute the binary the 
> result time is about 4 *milli*seconds. This happen when I use go1.16.
>
> When I use go1.15.8, on the same code, the exe is faster (about 120 
> microseconds) then the "go run mat.go" (about 180 microseconds). One order 
> of magnitude faster than go1.16 exe (and basic Matlab).
>
> So:
>
>- am I in error with the code (sorry, it's all new for me)? If yes, 
>where is my fault?
>- if the "benchmark" was correct, why go1.16 build executable is 
>slower than go1.15.8 exe and "go run" command?
>- Is it my machine's fault or Gonum package or what?
>- Do you also have these values?  
>
>
> My pc:  HP ELITEBOOK 8560w Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2201 
> Mhz, 4 Core(s), 8 Logical Processor(s) x64.
> I am on the *Windows Subsystem Linux 2. * 
>
>
> *Sorry for my English, I hope you understand my issue, thank you for the 
> attention*
>
>
>
>
>
>

-- 
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/54fa055b-1c1c-4ccb-a502-96872a00351cn%40googlegroups.com.

Re: [go-nuts] Error handling

[L Godioleskky]

Rust lang, very early in its evolution, saw the need to create its operator 
'?'  to more efficiently manage error handling. But the guardians of Go 
lang have resisted any changes to its clumsy method of error handling 
despite it being a major concern of Go users for a very long time. 


On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:

> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%40googlegroups.com.

[go-nuts] Re: Differences between go1.16 and go1.15 ?

[Volker Dobler]

1. Do not use go run main.go. Never!
2. Do not run your code with the much less problematic go run because
go run compiles and executes your code and the time needed to compile
it will ruin all benchmarks.
3. Always use the benchmarking infrastructure built into go test and 
and package testing.

On Saturday, 20 February 2021 at 15:48:32 UTC+1 TiT8 wrote:

> Hello everyone,
> I'm Lorenzo and I'm not a computer scientist, I have used some "Matlab" 
> and I am new with Go (surprisingly fast, simple and elegant).
>
> I'm trying to do some basic operation on matrix with the "Gonum" package 
> using vectorization. I was curious about the speed of development and the 
> performance (repeat... surprisingly for me!). So I've tried to do some 
> measures:
>
> *package main*
>
> *import (*
> *"fmt"*
> *"time"*
>
> *"gonum.org/v1/gonum/mat "*
> *)*
>
> *func main() {*
> *p := mat.NewDense(3, 3, nil)*
> *a := mat.NewDense(3, 3, []float64{*
> *1, 2, 3, 1, 2, 3, 1, 2, 3,*
> *})*
>
> *start := time.Now()*
>
> *p.Mul(a, a)  *// element-wise
> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
> *p.Add(a, a) *
> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
> *p.MulElem(a, a)*
> *fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
>
> *fmt.Println(time.Since(start))*
> *}*
>
>
> Well... when I run the "go run mat.go" command the result time is about 
> 150 microseconds, but when I run "go build" and then execute the binary the 
> result time is about 4 *milli*seconds. This happen when I use go1.16.
>
> When I use go1.15.8, on the same code, the exe is faster (about 120 
> microseconds) then the "go run mat.go" (about 180 microseconds). One order 
> of magnitude faster than go1.16 exe (and basic Matlab).
>
> So:
>
>- am I in error with the code (sorry, it's all new for me)? If yes, 
>where is my fault?
>- if the "benchmark" was correct, why go1.16 build executable is 
>slower than go1.15.8 exe and "go run" command?
>- Is it my machine's fault or Gonum package or what?
>- Do you also have these values?  
>
>
> My pc:  HP ELITEBOOK 8560w Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2201 
> Mhz, 4 Core(s), 8 Logical Processor(s) x64.
> I am on the *Windows Subsystem Linux 2. * 
>
>
> *Sorry for my English, I hope you understand my issue, thank you for the 
> attention*
>
>
>
>
>
>

-- 
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/9805b860-0a79-44ad-97d8-6ab16a181d8en%40googlegroups.com.

Re: [go-nuts] How do you test an unpublished module?

[Peter Kleiweg]

Reading https://github.com/rogpeppe/gohack en trying some things, I found 
that 
you *can* tell go.mod that it should use local files instead of a 
repository.

I have a test program outside my `~/go` tree with a `go.mod` like this:

```
module peter.nl/tester

go 1.16

replace github.com/pebbe/package => 
/home/peter/go/src/github.com/pebbe/package
```

Then I run this:
```
go get github.com/pebbe/package
```

Now I can build and run the test program, and when I change anything 
locally in 
`/home/peter/go/src/github.com/pebbe/package` and build the test program 
again,
it reflects the changes made in the package. This is exactly what I need.



Op zaterdag 20 februari 2021 om 13:45:15 UTC+1 schreef ohir:

> 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/529fd74b-aad4-4f93-ae19-df9e0a37723dn%40googlegroups.com.

[go-nuts] Differences between go1.16 and go1.15 ?

[TiT8]

Hello everyone,
I'm Lorenzo and I'm not a computer scientist, I have used some "Matlab" and 
I am new with Go (surprisingly fast, simple and elegant).

I'm trying to do some basic operation on matrix with the "Gonum" package 
using vectorization. I was curious about the speed of development and the 
performance (repeat... surprisingly for me!). So I've tried to do some 
measures:

*package main*

*import (*
*"fmt"*
*"time"*

*"gonum.org/v1/gonum/mat"*
*)*

*func main() {*
*p := mat.NewDense(3, 3, nil)*
*a := mat.NewDense(3, 3, []float64{*
*1, 2, 3, 1, 2, 3, 1, 2, 3,*
*})*

*start := time.Now()*

*p.Mul(a, a)  *// element-wise
*fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
*p.Add(a, a) *
*fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*
*p.MulElem(a, a)*
*fmt.Printf("%v\n", mat.Formatted(p, mat.Prefix(""), mat.Squeeze()))*

*fmt.Println(time.Since(start))*
*}*


Well... when I run the "go run mat.go" command the result time is about 150 
microseconds, but when I run "go build" and then execute the binary the 
result time is about 4 *milli*seconds. This happen when I use go1.16.

When I use go1.15.8, on the same code, the exe is faster (about 120 
microseconds) then the "go run mat.go" (about 180 microseconds). One order 
of magnitude faster than go1.16 exe (and basic Matlab).

So:

   - am I in error with the code (sorry, it's all new for me)? If yes, 
   where is my fault?
   - if the "benchmark" was correct, why go1.16 build executable is slower 
   than go1.15.8 exe and "go run" command?
   - Is it my machine's fault or Gonum package or what?
   - Do you also have these values?  
   

My pc:  HP ELITEBOOK 8560w Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 2201 
Mhz, 4 Core(s), 8 Logical Processor(s) x64.
I am on the *Windows Subsystem Linux 2. * 


*Sorry for my English, I hope you understand my issue, thank you for the 
attention*





-- 
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/4053bf3c-d0ec-4016-8afa-b777b7c2bd3dn%40googlegroups.com.

Re: [go-nuts] How do you test an unpublished module?

[Wojciech S. Czarnecki]

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.

[go-nuts] How do you test an unpublished module?

[Peter Kleiweg]

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.

Before modules, I would develop the package in ~/go/src, write the
test program somewhere else, and import the package. This doesn't work
with modules.

What does work is move the test program into a subdirectory of the
package, add that directory to .gitignore . This works, as long as the
test program doesn't need any non-standard packages that the package I
am writing needs.

When the test program needs more non-standard packages, I need to add
these to go.mod of the package I am developing, even though that
package itself doesn't need it.

When I give the directory with the test program its own go.mod then it
can't use the files in the parent directory as the imported package.

I turned it the other way around. I put the package I am writing in a
subdirectory of the test program. That works, as long as that subdirectory
doesn't have its own go.mod .

So, in one setup, I end up with a package with a go.mod with too many
dependencies. An in the other I end up with a package without a go.mod .

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?

-- 
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/5390153a-0c05-436e-888f-9ab911d75bf8n%40googlegroups.com.

Re: [go-nuts] Re: "go1.15 mod tidy" fails if the current project depends on a module containing a file using embed and guarded by "+build go1.16"

[tapi...@gmail.com]

reasonable. Thanks both for explanations.

On Friday, February 19, 2021 at 7:20:36 AM UTC-5 Amnon wrote:

> go mod tidy has to ignore build tags.
>
> Because if it did not ignore build tags, it would delete dependencies 
> needed by other platforms.
>
> On Friday, 19 February 2021 at 02:23:45 UTC Ian Lance Taylor wrote:
>
>> On Thu, Feb 18, 2021 at 3:29 PM tapi...@gmail.com  
>> wrote:
>> >
>> > Thanks for the link.
>> > So "go mod tidy" ignores build tags, and this is intended?
>>
>> That is my understanding, yes.
>>
>> Ian
>>
>>
>> > On Thursday, February 18, 2021 at 9:28:53 AM UTC-5 Ian Lance Taylor 
>> wrote:
>> >>
>> >> On Thu, Feb 18, 2021 at 1:06 AM tapi...@gmail.com  
>> wrote:
>> >> >
>> >> > BTW, "go1.15 build" succeeds.
>> >> >
>> >> > On Thursday, February 18, 2021 at 4:03:50 AM UTC-5 tapi...@gmail.com 
>> wrote:
>> >> >>
>> >> >> Does this mean the "+build go1.N" directive is only intended to 
>> cooperate with Go toolchain 1.N+?
>> >>
>> >>
>> >> See the discussion at https://golang.org/issue/43980.
>> >>
>> >> Ian
>> >
>> > --
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to golang-nuts...@googlegroups.com.
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9a4eb260-d5de-4a7d-89e3-e26a9ff41455n%40googlegroups.com
>> .
>>
>

-- 
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/4493d0de-d8b4-4092-9da8-10f9ebb5dffcn%40googlegroups.com.

Re: [go-nuts] Go Documentation for private github projects

[Martin Schnabel]

Hi,
this January a fork of gddo was was announced to this list. Take a look
https://godocs.io/

Best regards

On 20.02.21 08:13, Sankar P wrote:

Hi

We have a bunch of private repos in github with Go sources. We want to 
see the documentation for these repository sources in an easy to click URL.


We are comfortable with deploying a FOSS binary/service, which can 
authenticate to github as a dedicated user and get the repositories. Now 
I want to see the docs for this. What is the way to achieve this ?


In the past, I have used `godoc.org/github.com/ 
/ ` for public repos. I 
want to do similarly for private repos with the `godoc.org 
` replaced by our custom domain.


https://github.com/golang/gddo  project 
is archived and I do not know what is the recommended way now.


Also, we are in GCP and so if there is some easy hack to get this 
deployed in GCP via a single click or some such, that will also be good. 
Any pointers ?


--
Sankar P
http://psankar.blogspot.com 

--
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/CAMSEaH6OiuqY4Gx_pfbReBDE3JbdQNnUK8sovg_Q33ma45-9zQ%40mail.gmail.com 
.


--
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/29e3c8f8-b838-7512-035b-f365a405c553%40mb0.org.