Re: [go-nuts] Bets approach for test helper packages within same project

[Nagaev Boris]

Hi,

You can put test helpers to a separate package (directory), say
testhelper/ without a build tag. Code in that directory will use
regular code and it will have its own unit tests in testhelper/
directory. When you build your production binary, it won't include
such code, because it is not imported by any production code (directly
or indirectly). At the same time, you can import the "testhelper"
package from your integration tests as usual.

On Fri, Aug 4, 2023 at 11:01 AM josvazg  wrote:
>
> We are working on a project that requires some test helpers and mocks that, 
> ideally, should:
>
> - Helpers should be accessible by all testing code, unit tests, integration 
> or e2e.
>   - Note unit tests live along side normal code in their *_test.go files.
>   - The rest of tests will be on a separated test/ folder using a built 
> tag to avoid to be compiled in with regular code.
>
> - Helpers should not be part of the default exported module code.
>
> - Helpers do not need to be accessible by the regular code, just the test 
> code.
>
> - Helpers might need tests themselves.
>
> How can we achieve that in the simplest or cleanest way? We do not want to 
> create yet another project for just that, as it is only to be used within 
> this project.
>
> I was thinking about a build tag for such code and just put it on a regular 
> folder, such as testsupport/. But that would break unit tests that need that 
> unless you setup the build tag, which feels weird.
>
> Another option is to place the test support and the test that use them under 
> the same build tag and folder as test/. And run them separately with the 
> build tag. That creates a special category of unit tests, when they are not 
> integration or e2e but need supporting code from those test/support/ packages.
>
> Maybe use a module at testsupport/ separate from the rest of the code and use 
> it as a library from test code?
>
> Any better options?
> Or maybe there is a good known solution for this I should know about.
>
> Jose
>
> --
> 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/ca983d85-b5f5-423d-b949-71fa41b414ccn%40googlegroups.com.



-- 
Best regards,
Boris Nagaev

-- 
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/CAFC_Vt5Y2WWHck7H7_%3DOKrXZ_thwXtpHhNeNiT03HiR_ZjsTJQ%40mail.gmail.com.

Re: [go-nuts] Clarification on code snippet

[alchemist vk]

Thank you Axel and burak for clarification.  Now I am able to understand
the syntax. Thank you again.

With regards,
Venkatesh

On Fri, Aug 4, 2023 at 10:28 PM Axel Wagner 
wrote:

> Another relevant section is Calls  (emphasis
> mine):
>
>> A method call x.m() is valid if the method set of (the type of) x
>> contains m and the argument list can be assigned to the parameter list of
>> m. *If x is addressable and 's method set contains m, x.m() is
>> shorthand for ().m()*:
>
>
>
>
> On Fri, Aug 4, 2023 at 6:39 PM burak serdar  wrote:
>
>>
>>
>> On Fri, Aug 4, 2023 at 10:33 AM alchemist vk 
>> wrote:
>>
>>> Hi folks,
>>>  In below code, I am invoking receiver api show() via a simple uInteger
>>> type variable instead of pointer, by which it expects to be invoked . Go
>>> being  strict with type casing and I was expecting a compiler error. But to
>>> my surprise, it compiled and executed successfully.  Can you folks please
>>> explain this behavior.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *package mainimport "fmt"type uInteger intfunc main() {var x
>>> uInteger = 10x.show()*
>>>
>>
>> Above, the variable x is addressable, so the compiler passes  to
>> show().
>>
>> To call a pointer receiver method of a variable, that variable has to be
>> addressable (it doesn't have to be a pointer), so the compiler knows how to
>> pass the address of it. Here's how it is described in the spec:
>>
>> https://go.dev/ref/spec#Method_values
>>
>>
>>>
>>>
>>>
>>>
>>> *}func (x *uInteger) show() {   fmt.Printf("In show, x = %d\n", *x)}*
>>>
>>> Thanks in Advance,
>>> Venkatesh
>>>
>>> --
>>> 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/CAJr0cerqTGvQA56yQWVYW3F2Ms5vbwq3YyO%2But%3DzJ%2BM4rqf81A%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/CAMV2Rqq%2BZi7ioHi4PPXTmQ7du45LRJaEiSSWJpf1zeH%2Bq3Wjeg%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/CAJr0ceqs3eD%2BdxhPsN9nDrDXcg5Gc1HdzRAfw6L_uEwjA%2BuzgQ%40mail.gmail.com.

Re: [go-nuts] Re: Error handling

[Miguel Angel Rivera Notararigo]

On Fri, Aug 4, 2023, 13:57 Harri L  wrote:

> Yes, we can handle Go errors without language changes; that’s true. But
> how we should annotate errors? The presented version of CopyFile leads to
> following 'stuttering':
> cannot copy '/tmpfs/play' to './tmp33/not-exist.txt': cannot create
> destination: open ./tmp33/not-exist.txt: no such file or directory
>
>
You will notice there is repeated information, and it is because os.Create
adds meaningless context to the error message ("open
./tmp33/not-exist.txt"), file path is owned by caller, and caller should
handle its problems. It should be:

cannot copy '/tmpfs/play' to './tmp33/not-exist.txt': cannot create
destination: no such file or directory

I thinks its pretty easy to read. But if you prefer sed "s/: /\n\n/g":

cannot copy '/tmpfs/play' to './tmp33/not-exist.txt'

cannot create destination

no such file or directory

You don't even need a stack trace to know where it failed.

If you use pre-declared errors, you can even go further and do some
handling programmatically, like "errros.Is(err, Retry)" for retrying
without any complicated dependency.


You can get compact but informative error messages just by following K
> annotation rules:
>
>1. Annotate the function you are implementing
>2. Let the functions that you are calling do their own job
>
> copy file: open ./tmp33/not-exist.txt: no such file or directory
>
>
For me (personal opinion), that message is not easy to understand.

copy file
Is this a log message telling me it is copying some file? or is it an error
message?
open ./tmp33/not-exist.txt
Oh, cool, it was a log message, it is opening a file now, keep it going
buddy, you can copy that file :)
no such file or directory
Well, it is a failure, I guess. But now I don't know where it failed, is
that source or destination?

With previous message:

cannot copy '/tmpfs/play' to './tmp33/not-exist.txt'
No! why you do this to me?
cannot create destination
But WHY!? I have been so nice to you 'not-exist.txt'
no such file or directory
Oh, you don't even exist haha sorry, drama moment

(We would never get that error because os.Create creates the file, but I am
using your example)

Using specific annotation is a different topic, but the primary goal of
this error messages is being hints for developers. For end users you will
be probably using translations or anything else.

All of this is just basic error propagation, which can be automated to
> avoid annoying human errors. You can see three different error annotation
> scenarios of the FileCopy implementations in this playground
> .
>
> And the function itself is compact as well — and fully automated (tip:
> change the name of the function):
> func copyFile(src, dst string) (err error) { defer err2.Handle() r :=
> try.To1(os.Open(src)) defer r.Close() w := try.To1(os.Create(dst)) defer
> err2.Handle(, func() { os.Remove(dst) }) defer w.Close()
> try.To1(io.Copy(w, r)) return nil }
> ​
>

Not sure, but this looks like try-catch exceptions in Go.

-- 
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/CAF9DLCkGDsDOf9qUqmtux0D55Csc2n6%3DcKw_G9zUJBbSTi3SJA%40mail.gmail.com.

Re: [go-nuts] Why is type inference still so rudimentary?

[jimmy frasche]

I wish there were more cases where the types could be elided. Always
leaving it off would be a bad idea but how much to put in should be at
the author's discretion. There are times when it clarifies but more
times when it just adds extra steps. I know that the current rules
have justifications but they still feel entirely arbitrary and it's
getting to be one of the more annoying aspects of reading and writing
Go (because most everything else has been addressed!)

On Fri, Aug 4, 2023 at 10:39 AM Ian Lance Taylor  wrote:
>
> On Fri, Aug 4, 2023 at 8:08 AM Nate Finch  wrote:
> >
> > If I have a struct
> >
> > type User struct {
> > Name string
> > ID int
> > }
> >
> > type Group struct {
> >  Leader  User
> > }
> >
> > Why is it that the go tool can't infer what type I'm constructing for the 
> > Leader field here?
> >
> > g := Group{
> > Leader: {
> >Name: "Jamie",
> >ID: 5,
> > },
> > }
> >
> > Cleary, the compiler knows I'm constructing a variable of type Group, and 
> > thus should know that Leader: is a field in Group, and thus what type I am 
> > constructing to assign to that field.  It's not like it's an interface 
> > where I could be assigning anything.
> >
> > Finally, why does this work with maps, but not struct fields?
> >
> > users := map[string]User {
> > "Jamie" : {
> >Name: "Jamie",
> >ID: 5,
> >  },
> > }
> >
> > This works and feels almost identical to the Group code above. Define the 
> > enclosing type, and then the subtype is obvious and thus implicit.
> >
> > I presume this is some parser thing where it can't distinguish between two 
> > possible valid constructions, though I can't think of exactly what other 
> > construction it might mean
>
> I think this is https://go.dev/issue/12854.  At least that is related.
>
> The reason we don't do it today boils down to: we implemented it in
> gofmt -s and weren't really happy with how it looked.  A number of
> existing composite literals became nearly unreadable when the types
> were omitted.  They were just collections of braces and elements, and
> it was hard to tell what they meant.  That was a long time ago and we
> may feel differently now, if somebody wants to seriously investigate.
>
> 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/CAOyqgcVTbE%3DxqDDO64d5ZOXD7VgOcNf0WzZzNP5T_esJ6HTP1Q%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/CANG3jXLGmtba2AS%3DPaFUnDbbFb-439HYSWD_oQ7ckXhYKt-wsA%40mail.gmail.com.

Re: [go-nuts] Re: Error handling

[Harri L]

Yes, we can handle Go errors without language changes; that’s true. But how 
we should annotate errors? The presented version of CopyFile leads to 
following 'stuttering':
cannot copy '/tmpfs/play' to './tmp33/not-exist.txt': cannot create 
destination: open ./tmp33/not-exist.txt: no such file or directory 

You can get compact but informative error messages just by following K 
annotation rules:

   1. Annotate the function you are implementing 
   2. Let the functions that you are calling do their own job 

copy file: open ./tmp33/not-exist.txt: no such file or directory 

All of this is just basic error propagation, which can be automated to 
avoid annoying human errors. You can see three different error annotation 
scenarios of the FileCopy implementations in this playground 
.

And the function itself is compact as well — and fully automated (tip: 
change the name of the function):
func copyFile(src, dst string) (err error) { defer err2.Handle() r := 
try.To1(os.Open(src)) defer r.Close() w := try.To1(os.Create(dst)) defer 
err2.Handle(, func() { os.Remove(dst) }) defer w.Close() 
try.To1(io.Copy(w, r)) return nil } 
​
On Friday, August 4, 2023 at 6:07:52 AM UTC+3 Miguel Angel Rivera 
Notararigo wrote:

> func CopyFile(src, dst string) error {
> r, err := os.Open(src)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> defer r.Close()
>
> w, err := os.Create(dst)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if _, err := io.Copy(w, r); err != nil {
> w.Close()
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if err := w.Close(); err != nil {
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> }
>
> I think it is a bad example, how do you know where CopyFile failed?
>
> The "copy ..." part shouldn't be in there, you should add valuable context 
> to your errors, if CopyFile fails, the caller already knows it was a copy 
> error because the function has a big "Copy" on his name right? you should 
> do this instead:
>
> func CopyFile(dst, src string) error {
>   r, errOS := os.Open(src) // Avoid shadowing errors, don't use err
>   if errOS != nil {
> return fmt.Errorf("cannot open source: %v", errOS)
>   }
>
>   defer r.Close()
>
>   w, errCD := os.Create(dst)
>   if errCD != nil {
> return fmt.Errorf("cannot create destination: %v", errCD)
>   }
>
>   defer w.Close()
>
>   if _, err := io.Copy(w, r); err != nil { // Local scope error, so err is 
> fine
> os.Remove(dst)
> return fmt.Errorf("cannot copy data from source: %v", err)
>
>   }
>
>   if err := w.Close(); err != nil {
> os.Remove(dst)
> return fmt.Errorf("cannot close destination", err)
>   }
> }
>
> // Caller should do this.
> if err := CopyFile("dst.txt", "src.txt"); err != nil {
>   // Here is where you should add 'copy' to the error message.
>   return fmt.Errorf("cannot copy '%s' to '%s': %v", src, dst, err)
> }
>
> People complaining about Go's error handling regularly don't handle 
> errors, they just throw them like exceptions.
>
> If you really hate Go's error handling, just use:
>
> func catch(err error) {
>   if err != nil {
> panic(err)
>   }
>
>   // And use recover somewhere
> }
>
> Which is a bad practice, but at least we (the people who like how Go 
> handle errors) can still handle our errors without any language change.
>
> On Tue, Aug 1, 2023, 13:06 DrGo  wrote:
>
>> Thanks. 
>> The keystroke saving is not the motivation. The aim is to reduce the code 
>> reader’s mental load. My approach allows for clearer code where the main 
>> program logic is not dwarfed by the error handling code while maintaining 
>> the explicitly of error handling and the possible error-induced 
>> interruption in program flow. It avoids creating new if scope when one is 
>> not desired and offers opportunities for further deduplication of error 
>> handling code although each error is still handled individually. Compare 
>> the following; which one would you prefer to read a lot of?
>>
>> - current approach; error handling to program logic ratio: 13:5 
>>
>> func CopyFile(src, dst string) error {
>> r, err := os.Open(src)
>> if err != nil {
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>> defer r.Close()
>>
>> w, err := os.Create(dst)
>> if err != nil {
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>>
>> if _, err := io.Copy(w, r); err != nil {
>> w.Close()
>> os.Remove(dst)
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>>
>> if err := w.Close(); err != nil {
>> os.Remove(dst)
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>> }
>>
>> - new approach ratio 5:5
>> func CopyFile(src, dst string) error {
>> r, err := os.Open(src) *orelse* return fmt.Errorf("copy %s %s: %v", src, 
>> dst, err)
>> defer r.Close()
>>
>> w, err := os.Create(dst); *orelse* return fmt.Errorf("copy %s %s: %v", 
>> src, dst, err)
>> err := io.Copy(w, r) 

Re: [go-nuts] Why is type inference still so rudimentary?

[Ian Lance Taylor]

On Fri, Aug 4, 2023 at 8:08 AM Nate Finch  wrote:
>
> If I have a struct
>
> type User struct {
> Name string
> ID int
> }
>
> type Group struct {
>  Leader  User
> }
>
> Why is it that the go tool can't infer what type I'm constructing for the 
> Leader field here?
>
> g := Group{
> Leader: {
>Name: "Jamie",
>ID: 5,
> },
> }
>
> Cleary, the compiler knows I'm constructing a variable of type Group, and 
> thus should know that Leader: is a field in Group, and thus what type I am 
> constructing to assign to that field.  It's not like it's an interface where 
> I could be assigning anything.
>
> Finally, why does this work with maps, but not struct fields?
>
> users := map[string]User {
> "Jamie" : {
>Name: "Jamie",
>ID: 5,
>  },
> }
>
> This works and feels almost identical to the Group code above. Define the 
> enclosing type, and then the subtype is obvious and thus implicit.
>
> I presume this is some parser thing where it can't distinguish between two 
> possible valid constructions, though I can't think of exactly what other 
> construction it might mean

I think this is https://go.dev/issue/12854.  At least that is related.

The reason we don't do it today boils down to: we implemented it in
gofmt -s and weren't really happy with how it looked.  A number of
existing composite literals became nearly unreadable when the types
were omitted.  They were just collections of braces and elements, and
it was hard to tell what they meant.  That was a long time ago and we
may feel differently now, if somebody wants to seriously investigate.

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/CAOyqgcVTbE%3DxqDDO64d5ZOXD7VgOcNf0WzZzNP5T_esJ6HTP1Q%40mail.gmail.com.

Re: [go-nuts] Clarification on code snippet

['Axel Wagner' via golang-nuts]

Another relevant section is Calls  (emphasis
mine):

> A method call x.m() is valid if the method set of (the type of) x contains
> m and the argument list can be assigned to the parameter list of m. *If x
> is addressable and 's method set contains m, x.m() is shorthand for
> ().m()*:




On Fri, Aug 4, 2023 at 6:39 PM burak serdar  wrote:

>
>
> On Fri, Aug 4, 2023 at 10:33 AM alchemist vk 
> wrote:
>
>> Hi folks,
>>  In below code, I am invoking receiver api show() via a simple uInteger
>> type variable instead of pointer, by which it expects to be invoked . Go
>> being  strict with type casing and I was expecting a compiler error. But to
>> my surprise, it compiled and executed successfully.  Can you folks please
>> explain this behavior.
>>
>>
>>
>>
>>
>>
>>
>>
>> *package mainimport "fmt"type uInteger intfunc main() {var x uInteger
>> = 10x.show()*
>>
>
> Above, the variable x is addressable, so the compiler passes  to show().
>
> To call a pointer receiver method of a variable, that variable has to be
> addressable (it doesn't have to be a pointer), so the compiler knows how to
> pass the address of it. Here's how it is described in the spec:
>
> https://go.dev/ref/spec#Method_values
>
>
>>
>>
>>
>>
>> *}func (x *uInteger) show() {   fmt.Printf("In show, x = %d\n", *x)}*
>>
>> Thanks in Advance,
>> Venkatesh
>>
>> --
>> 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/CAJr0cerqTGvQA56yQWVYW3F2Ms5vbwq3YyO%2But%3DzJ%2BM4rqf81A%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/CAMV2Rqq%2BZi7ioHi4PPXTmQ7du45LRJaEiSSWJpf1zeH%2Bq3Wjeg%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/CAEkBMfEaeUm3kRb6%2B6e5UMh_vx9RfQkCN7fiHGxtyDDQgU%3DGNQ%40mail.gmail.com.

Re: [go-nuts] Re: Error handling

[DrGo]

Thanks Miguel and I am not offended.. It sounds you like the proposal and 
your comments were not about the proposal per se but about the cultural 
issues surrounding change and fear of unnecessary growth; here we agree too.


On Friday, August 4, 2023 at 6:47:37 AM UTC-6 Miguel Angel Rivera 
Notararigo wrote:

>
>
> On Thu, Aug 3, 2023, 23:45 DrGo  wrote:
>
>> @Miguel Angel Rivera Notararigo
>>
>> Thanks for taking the time to write... 
>>
>> In my proposal, people are free to add as much context as they want...
>>
>
> Yeah I know, I like your proposal, it is just how they handle errors in 
> the V programming language, although they use the keyword "or" and have 
> Options/Results. 
>
> but as a demonstration, I am using the example from 
>> Ross Cox's paper on error handling that is used by all error handling 
>> proposals to show case their approach. I do not think Ross will 
>> take your criticism personally :) 
>>
>
> I know, but just because he wrote that, doesn't mean it is the perfect 
> example. If I find myself writing code like that, I would probably hate 
> Go's error handling too, but that might be said for any other feature of 
> the language if I write some bad looking examples.
>
> I don't see how he could take my opinion personally, I didn't mean to be 
> rude, I just said it is a bad example. I am not a native speaker, so my 
> apologies if I wrote something rude.
>
> I on the other hand take exception to your generalization re people who 
>> complain about error handling in Go.
>> I am sure you did not make that claim without having some sort of solid 
>> research to support it. But, Go designers themselves admit that this is an 
>> issue and have written
>> tons on it.
>>
>
> You don't need a research or statistics if the complain is: "I don't want 
> to write 'if err != nil { return err }' every single time".
>
> It means they use "if err := w.Close(); err != nil { return err }" for 
> throwing the error, right? It is literally what they said or am I assuming?
>
> This same people will complain about your proposal, "I don't want to write 
> 'orelse return err' every single time", and then we will add 'w.Close()!' 
> or 'try w.Close()' to the language, and then we will be very happy with our 
> Go++ wich has 3 ways of doing the same thing.
>
>
>> In one or two replies above we were discussing how error handling 
>> opinions can become religions each with its own priests who think they are 
>> the only saved faction, and that their rituals are the only right approach 
>> for all situations.
>>
>
> I know, as I said, I like your proposal, but one of Go best features is 
> the lack of new features. I am arguing against my own taste, because I like 
> 'w.Close() or return fmt.Errorf("cannot close destination: %v", err)', but 
> I like more the simplicity of Go.
>
>
>> Best wishes,
>>
>>
>> On Thursday, August 3, 2023 at 9:07:52 PM UTC-6 Miguel Angel Rivera 
>> Notararigo wrote:
>>
>> func CopyFile(src, dst string) error {
>> r, err := os.Open(src)
>> if err != nil {
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>> defer r.Close()
>>
>> w, err := os.Create(dst)
>> if err != nil {
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>>
>> if _, err := io.Copy(w, r); err != nil {
>> w.Close()
>> os.Remove(dst)
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>>
>> if err := w.Close(); err != nil {
>> os.Remove(dst)
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>> }
>>
>> I think it is a bad example, how do you know where CopyFile failed?
>>
>> The "copy ..." part shouldn't be in there, you should add valuable 
>> context to your errors, if CopyFile fails, the caller already knows it was 
>> a copy error because the function has a big "Copy" on his name right? you 
>> should do this instead:
>>
>> func CopyFile(dst, src string) error {
>>   r, errOS := os.Open(src) // Avoid shadowing errors, don't use err
>>   if errOS != nil {
>> return fmt.Errorf("cannot open source: %v", errOS)
>>   }
>>
>>   defer r.Close()
>>
>>   w, errCD := os.Create(dst)
>>   if errCD != nil {
>> return fmt.Errorf("cannot create destination: %v", errCD)
>>   }
>>
>>   defer w.Close()
>>
>>   if _, err := io.Copy(w, r); err != nil { // Local scope error, so err 
>> is fine
>> os.Remove(dst)
>> return fmt.Errorf("cannot copy data from source: %v", err)
>>
>>   }
>>
>>   if err := w.Close(); err != nil {
>> os.Remove(dst)
>> return fmt.Errorf("cannot close destination", err)
>>   }
>> }
>>
>> // Caller should do this.
>> if err := CopyFile("dst.txt", "src.txt"); err != nil {
>>   // Here is where you should add 'copy' to the error message.
>>   return fmt.Errorf("cannot copy '%s' to '%s': %v", src, dst, err)
>> }
>>
>> People complaining about Go's error handling regularly don't handle 
>> errors, they just throw them like exceptions.
>>
>> If you really hate Go's error handling, just use:
>>
>> func catch(err error) {
>>   if err != nil {
>> 

Re: [go-nuts] Clarification on code snippet

[burak serdar]

On Fri, Aug 4, 2023 at 10:33 AM alchemist vk  wrote:

> Hi folks,
>  In below code, I am invoking receiver api show() via a simple uInteger
> type variable instead of pointer, by which it expects to be invoked . Go
> being  strict with type casing and I was expecting a compiler error. But to
> my surprise, it compiled and executed successfully.  Can you folks please
> explain this behavior.
>
>
>
>
>
>
>
>
> *package mainimport "fmt"type uInteger intfunc main() {var x uInteger
> = 10x.show()*
>

Above, the variable x is addressable, so the compiler passes  to show().

To call a pointer receiver method of a variable, that variable has to be
addressable (it doesn't have to be a pointer), so the compiler knows how to
pass the address of it. Here's how it is described in the spec:

https://go.dev/ref/spec#Method_values


>
>
>
>
> *}func (x *uInteger) show() {   fmt.Printf("In show, x = %d\n", *x)}*
>
> Thanks in Advance,
> Venkatesh
>
> --
> 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/CAJr0cerqTGvQA56yQWVYW3F2Ms5vbwq3YyO%2But%3DzJ%2BM4rqf81A%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/CAMV2Rqq%2BZi7ioHi4PPXTmQ7du45LRJaEiSSWJpf1zeH%2Bq3Wjeg%40mail.gmail.com.

[go-nuts] glog symbolic link flag is not used

[Martins Ungurs]

Hello!

glog's flag "log_link" is defined, but not used. Symbolic links are created
without using this flag.
https://github.com/golang/glog/blob/master/glog_file.go#L46


Thanks,
Martin.

-- 
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/CAGHiyGbcOR5-_dTrAcDdk2Se2oXnJNyzpc4v6UhsLqOApH%3Dd4A%40mail.gmail.com.

[go-nuts] Clarification on code snippet

[alchemist vk]

Hi folks,
 In below code, I am invoking receiver api show() via a simple uInteger
type variable instead of pointer, by which it expects to be invoked . Go
being  strict with type casing and I was expecting a compiler error. But to
my surprise, it compiled and executed successfully.  Can you folks please
explain this behavior.












*package mainimport "fmt"type uInteger intfunc main() {var x uInteger =
10x.show()}func (x *uInteger) show() {   fmt.Printf("In show, x =
%d\n", *x)}*

Thanks in Advance,
Venkatesh

-- 
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/CAJr0cerqTGvQA56yQWVYW3F2Ms5vbwq3YyO%2But%3DzJ%2BM4rqf81A%40mail.gmail.com.

[go-nuts] Resident set not decreasing after load decreased

[Dilshan Sandhu]

Hi,
I am working on a chat application build with golang. I am using 
open-source server tinode (https://github.com/tinode/chat) as base for my 
chat application. Issue is I am facing is the Resident set (as shown by 
top) shows very high memory usage after a load test ends. Also increasing 
channel capacity is resulting in higher end res value.
Some terminology about server. 
Topic:- Group is a topic, If i am coming online a topic is created, when 
two users chat, topic is created. 
I did some tests with different topic queue limits (hub.go:run():case 
join). Check scenario 1(og) and scenario2(modified). A gatling test was ran 
against both these conditions(and everything else same). At the start and 
end of each test(all ws closed), we noted the Resident Set (as given by 
htop)(these values remained stable after 5min also).
 BeforeAfter
A  417M  1.71G
B  419M  2.09G

This indicates that the channels are not being cleaned for a topic which is 
not active. Any inputs would be helpful. 

Scenario1(A)
clientMsg: make(chan *ClientComMessage, 192),
serverMsg: make(chan *ServerComMessage, 64),
reg: make(chan *ClientComMessage, 256),
unreg: make(chan *ClientComMessage, 256),
meta: make(chan *ClientComMessage, 64),

Scenario2(B)
clientMsg: make(chan *ClientComMessage, 4096),
serverMsg: make(chan *ServerComMessage, 4096),
reg: make(chan *ClientComMessage, 4096),
unreg: make(chan *ClientComMessage, 4096),
meta: make(chan *ClientComMessage, 128),
At the start df

-- 
“The information contained in this message is intended for the addressee 
only and may contain classified information. If you are not the addressee, 
please delete this message and notify the sender; you should not copy or 
distribute this message or disclose its contents to anyone. Any views or 
opinions expressed in this message are those of the individual(s) and not 
necessarily of the Docquity. No reliance may be placed on this message 
without written confirmation from an authorised representative of its 
contents.”

-- 
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/a1cf9cbd-a198-4da6-97ec-79814fc46df9n%40googlegroups.com.

[go-nuts] Why is type inference still so rudimentary?

[Nate Finch]

If I have a struct

type User struct {
Name string
ID int
}

type Group struct {
 Leader  User
}

Why is it that the go tool can't infer what type I'm constructing for the 
Leader field here?

g := Group{
Leader: {
   Name: "Jamie",
   ID: 5,
},
}

Cleary, the compiler knows I'm constructing a variable of type Group, and 
thus should know that Leader: is a field in Group, and thus what type I am 
constructing to assign to that field.  It's not like it's an interface 
where I could be assigning anything.

Finally, why does this work with maps, but not struct fields?

users := map[string]User {
"Jamie" : { 
   Name: "Jamie",
   ID: 5,
 },
}

This *works* and feels almost identical to the Group code above. Define the 
enclosing type, and then the subtype is obvious and thus implicit.

I presume this is some parser thing where it can't distinguish between two 
possible valid constructions, though I can't think of exactly what other 
construction it might mean

-- 
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/16e7b06e-0b22-4997-bf1e-8d9b251f3c23n%40googlegroups.com.

Re: [go-nuts] Re: How to convert an svg to a png (or gif) image?

[Jan Mercl]

On Fri, Aug 4, 2023 at 1:22 PM Brian Candler  wrote:

> Also there's a project which compiles C code to Go - ISTR it was used to 
> build a pure Go version of Sqlite.  Presumably the same approach could be 
> applied to an image processing library.
>
> https://twitter.com/bradfitz/status/855271867162083329?lang=en
> https://groups.google.com/g/golang-nuts/c/QDEczMhlQBU/m/4lCn2kP0AwAJ
> https://github.com/elliotchance/c2go

ccgo/v3 is being slowly phased out. ccgo/v4 is not yet released, but
maybe it can already transpile a C SVG to PNG code base and I'd like
to try that to at least know where it fails.

A quick search found no such C code, but that might be my fault. Does
anyone know about a pure C SVG to PNG lib/program?

-j

-- 
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/CAA40n-WLtSqLRmsYvCX1UtdnxhtPJEdDR0T%3DoSg8EXZUkPHDVw%40mail.gmail.com.

Re: [go-nuts] Re: Error handling

[Victor Giordano]

Ok, that is a point to have in mind.

El vie, 4 ago 2023 a las 10:37, Miguel Angel Rivera Notararigo (<
ntr...@gmail.com>) escribió:

> I understand, but there is a little difference, you can find code out
> there improving performance thanks to generics, I am not sure if we can get
> any performance improvement by using "orelse return err".
>
>>

-- 
V

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

[go-nuts] Bets approach for test helper packages within same project

[josvazg]

We are working on a project that requires some test helpers and mocks that, 
ideally, should:

- Helpers should be accessible by all testing code, unit tests, integration 
or e2e. 
  - Note unit tests live along side normal code in their *_test.go 
files.
  - The rest of tests will be on a separated test/ folder using a built 
tag to avoid to be compiled in with regular code.

- Helpers should not be part of the default exported module code.

- Helpers do not need to be accessible by the regular code, just the test 
code.

- Helpers might need tests themselves.

How can we achieve that in the simplest or cleanest way? We do not want to 
create yet another project for just that, as it is only to be used within 
this project.

I was thinking about a build tag for such code and just put it on a regular 
folder, such as testsupport/. But that would break unit tests that need 
that unless you setup the build tag, which feels weird.

Another option is to place the test support and the test that use them 
under the same build tag and folder as test/. And run them separately with 
the build tag. That creates a special category of unit tests, when they are 
not integration or e2e but need supporting code from those test/support/ 
packages.

Maybe use a module at testsupport/ separate from the rest of the code and 
use it as a library from test code?

Any better options?
Or maybe there is a good known solution for this I should know about.

Jose

-- 
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/ca983d85-b5f5-423d-b949-71fa41b414ccn%40googlegroups.com.

[go-nuts] slog's use of runtime.Callers() with a skip

['sh...@tigera.io' via golang-nuts]

I was looking at replacing logrus with the new slog library in our project. 
 I noticed that it uses runtime.Callers() with a fixed skip 
 to 
collect the PC of the calling code, presumably to make it possible for the 
handler to emit line number and filename.

Question is: is that sound in the face of inlining functions?  I think if 
the Info method gets inlined then the skip might be too large, for example.

I remember having to change similar code in our project to use 
runtime.CallersFrames in order to deal with inlining. Quite possible 
there's a way to deal with an inlined PC that I wasn't aware of, but it 
seemed wrong to me.

-Shaun

-- 
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/62c4950a-bf24-40f6-a17b-b3ef20099be4n%40googlegroups.com.

Re: [go-nuts] Re: Error handling

[Miguel Angel Rivera Notararigo]

I understand, but there is a little difference, you can find code out there
improving performance thanks to generics, I am not sure if we can get any
performance improvement by using "orelse return err".

>

-- 
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/CAF9DLCkBtF37j0tKpu%2BWoHBhEfE5iQ7ygWw0eDVg-HcAUzUsCA%40mail.gmail.com.

Re: [go-nuts] Re: Error handling

[Victor Giordano]

> Generics add a lot of value

>From a personal point of view with the interfaces I got all the genericity
I needed to model solutions, and generics per se doesn't provide a new
approach to find solutions.
I Mean, you can solve the same old problems with or without generics...
Generics provides another way of writing code, just as this proposal to
deal with errors. This is my view on this matter.



El vie, 4 ago 2023 a las 10:16, Miguel Angel Rivera Notararigo (<
ntr...@gmail.com>) escribió:

> It is not just resistance to change, it is about not adding new features
> that add more complexity than value. I am pretty sure people will complain
> about Go's error handling even if we use "orelse return err".
>
> Generics add a lot of value, it shows the Go team is open to changes. But
> imagine they add any feature people ask, C++ would be simpler than Go.
>
> As I said, I like the proposal, but I have learned that some times, I have
> to accept things are not always as I want them to be.
>
> On Fri, Aug 4, 2023, 08:58 Victor Giordano  wrote:
>
>> As far as I see things there is always room for changes... but changes
>> doesn't come without some resistance.. That is natural...
>>
>> >  Go best features is the lack of new features.
>>
>> What about generics? That was a major change... It was really necessary
>> or not is another topic.
>>
>> El vie, 4 ago 2023 a las 9:47, Miguel Angel Rivera Notararigo (<
>> ntr...@gmail.com>) escribió:
>>
>>>
>>>
>>> On Thu, Aug 3, 2023, 23:45 DrGo  wrote:
>>>
 @Miguel Angel Rivera Notararigo

 Thanks for taking the time to write...

 In my proposal, people are free to add as much context as they want...

>>>
>>> Yeah I know, I like your proposal, it is just how they handle errors in
>>> the V programming language, although they use the keyword "or" and have
>>> Options/Results.
>>>
>>> but as a demonstration, I am using the example from
 Ross Cox's paper on error handling that is used by all error handling
 proposals to show case their approach. I do not think Ross will
 take your criticism personally :)

>>>
>>> I know, but just because he wrote that, doesn't mean it is the perfect
>>> example. If I find myself writing code like that, I would probably hate
>>> Go's error handling too, but that might be said for any other feature of
>>> the language if I write some bad looking examples.
>>>
>>> I don't see how he could take my opinion personally, I didn't mean to be
>>> rude, I just said it is a bad example. I am not a native speaker, so my
>>> apologies if I wrote something rude.
>>>
>>> I on the other hand take exception to your generalization re people who
 complain about error handling in Go.
 I am sure you did not make that claim without having some sort of solid
 research to support it. But, Go designers themselves admit that this is an
 issue and have written
 tons on it.

>>>
>>> You don't need a research or statistics if the complain is: "I don't
>>> want to write 'if err != nil { return err }' every single time".
>>>
>>> It means they use "if err := w.Close(); err != nil { return err }" for
>>> throwing the error, right? It is literally what they said or am I assuming?
>>>
>>> This same people will complain about your proposal, "I don't want to
>>> write 'orelse return err' every single time", and then we will add
>>> 'w.Close()!' or 'try w.Close()' to the language, and then we will be very
>>> happy with our Go++ wich has 3 ways of doing the same thing.
>>>
>>>
 In one or two replies above we were discussing how error handling
 opinions can become religions each with its own priests who think they are
 the only saved faction, and that their rituals are the only right approach
 for all situations.

>>>
>>> I know, as I said, I like your proposal, but one of Go best features is
>>> the lack of new features. I am arguing against my own taste, because I like
>>> 'w.Close() or return fmt.Errorf("cannot close destination: %v", err)', but
>>> I like more the simplicity of Go.
>>>
>>>
 Best wishes,


 On Thursday, August 3, 2023 at 9:07:52 PM UTC-6 Miguel Angel Rivera
 Notararigo wrote:

 func CopyFile(src, dst string) error {
 r, err := os.Open(src)
 if err != nil {
 return fmt.Errorf("copy %s %s: %v", src, dst, err)
 }
 defer r.Close()

 w, err := os.Create(dst)
 if err != nil {
 return fmt.Errorf("copy %s %s: %v", src, dst, err)
 }

 if _, err := io.Copy(w, r); err != nil {
 w.Close()
 os.Remove(dst)
 return fmt.Errorf("copy %s %s: %v", src, dst, err)
 }

 if err := w.Close(); err != nil {
 os.Remove(dst)
 return fmt.Errorf("copy %s %s: %v", src, dst, err)
 }
 }

 I think it is a bad example, how do you know where CopyFile failed?

 The "copy ..." part shouldn't be in there, you should add valuable
 context to your errors, if CopyFile fails, the caller 

Re: [go-nuts] Re: Error handling

[Miguel Angel Rivera Notararigo]

It is not just resistance to change, it is about not adding new features
that add more complexity than value. I am pretty sure people will complain
about Go's error handling even if we use "orelse return err".

Generics add a lot of value, it shows the Go team is open to changes. But
imagine they add any feature people ask, C++ would be simpler than Go.

As I said, I like the proposal, but I have learned that some times, I have
to accept things are not always as I want them to be.

On Fri, Aug 4, 2023, 08:58 Victor Giordano  wrote:

> As far as I see things there is always room for changes... but changes
> doesn't come without some resistance.. That is natural...
>
> >  Go best features is the lack of new features.
>
> What about generics? That was a major change... It was really necessary or
> not is another topic.
>
> El vie, 4 ago 2023 a las 9:47, Miguel Angel Rivera Notararigo (<
> ntr...@gmail.com>) escribió:
>
>>
>>
>> On Thu, Aug 3, 2023, 23:45 DrGo  wrote:
>>
>>> @Miguel Angel Rivera Notararigo
>>>
>>> Thanks for taking the time to write...
>>>
>>> In my proposal, people are free to add as much context as they want...
>>>
>>
>> Yeah I know, I like your proposal, it is just how they handle errors in
>> the V programming language, although they use the keyword "or" and have
>> Options/Results.
>>
>> but as a demonstration, I am using the example from
>>> Ross Cox's paper on error handling that is used by all error handling
>>> proposals to show case their approach. I do not think Ross will
>>> take your criticism personally :)
>>>
>>
>> I know, but just because he wrote that, doesn't mean it is the perfect
>> example. If I find myself writing code like that, I would probably hate
>> Go's error handling too, but that might be said for any other feature of
>> the language if I write some bad looking examples.
>>
>> I don't see how he could take my opinion personally, I didn't mean to be
>> rude, I just said it is a bad example. I am not a native speaker, so my
>> apologies if I wrote something rude.
>>
>> I on the other hand take exception to your generalization re people who
>>> complain about error handling in Go.
>>> I am sure you did not make that claim without having some sort of solid
>>> research to support it. But, Go designers themselves admit that this is an
>>> issue and have written
>>> tons on it.
>>>
>>
>> You don't need a research or statistics if the complain is: "I don't want
>> to write 'if err != nil { return err }' every single time".
>>
>> It means they use "if err := w.Close(); err != nil { return err }" for
>> throwing the error, right? It is literally what they said or am I assuming?
>>
>> This same people will complain about your proposal, "I don't want to
>> write 'orelse return err' every single time", and then we will add
>> 'w.Close()!' or 'try w.Close()' to the language, and then we will be very
>> happy with our Go++ wich has 3 ways of doing the same thing.
>>
>>
>>> In one or two replies above we were discussing how error handling
>>> opinions can become religions each with its own priests who think they are
>>> the only saved faction, and that their rituals are the only right approach
>>> for all situations.
>>>
>>
>> I know, as I said, I like your proposal, but one of Go best features is
>> the lack of new features. I am arguing against my own taste, because I like
>> 'w.Close() or return fmt.Errorf("cannot close destination: %v", err)', but
>> I like more the simplicity of Go.
>>
>>
>>> Best wishes,
>>>
>>>
>>> On Thursday, August 3, 2023 at 9:07:52 PM UTC-6 Miguel Angel Rivera
>>> Notararigo wrote:
>>>
>>> func CopyFile(src, dst string) error {
>>> r, err := os.Open(src)
>>> if err != nil {
>>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>>> }
>>> defer r.Close()
>>>
>>> w, err := os.Create(dst)
>>> if err != nil {
>>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>>> }
>>>
>>> if _, err := io.Copy(w, r); err != nil {
>>> w.Close()
>>> os.Remove(dst)
>>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>>> }
>>>
>>> if err := w.Close(); err != nil {
>>> os.Remove(dst)
>>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>>> }
>>> }
>>>
>>> I think it is a bad example, how do you know where CopyFile failed?
>>>
>>> The "copy ..." part shouldn't be in there, you should add valuable
>>> context to your errors, if CopyFile fails, the caller already knows it was
>>> a copy error because the function has a big "Copy" on his name right? you
>>> should do this instead:
>>>
>>> func CopyFile(dst, src string) error {
>>>   r, errOS := os.Open(src) // Avoid shadowing errors, don't use err
>>>   if errOS != nil {
>>> return fmt.Errorf("cannot open source: %v", errOS)
>>>   }
>>>
>>>   defer r.Close()
>>>
>>>   w, errCD := os.Create(dst)
>>>   if errCD != nil {
>>> return fmt.Errorf("cannot create destination: %v", errCD)
>>>   }
>>>
>>>   defer w.Close()
>>>
>>>   if _, err := io.Copy(w, r); err != nil { // Local scope error, so err
>>> is fine
>>> 

Re: [go-nuts] Re: Error handling

[Victor Giordano]

As far as I see things there is always room for changes... but changes
doesn't come without some resistance.. That is natural...

>  Go best features is the lack of new features.

What about generics? That was a major change... It was really necessary or
not is another topic.

El vie, 4 ago 2023 a las 9:47, Miguel Angel Rivera Notararigo (<
ntr...@gmail.com>) escribió:

>
>
> On Thu, Aug 3, 2023, 23:45 DrGo  wrote:
>
>> @Miguel Angel Rivera Notararigo
>>
>> Thanks for taking the time to write...
>>
>> In my proposal, people are free to add as much context as they want...
>>
>
> Yeah I know, I like your proposal, it is just how they handle errors in
> the V programming language, although they use the keyword "or" and have
> Options/Results.
>
> but as a demonstration, I am using the example from
>> Ross Cox's paper on error handling that is used by all error handling
>> proposals to show case their approach. I do not think Ross will
>> take your criticism personally :)
>>
>
> I know, but just because he wrote that, doesn't mean it is the perfect
> example. If I find myself writing code like that, I would probably hate
> Go's error handling too, but that might be said for any other feature of
> the language if I write some bad looking examples.
>
> I don't see how he could take my opinion personally, I didn't mean to be
> rude, I just said it is a bad example. I am not a native speaker, so my
> apologies if I wrote something rude.
>
> I on the other hand take exception to your generalization re people who
>> complain about error handling in Go.
>> I am sure you did not make that claim without having some sort of solid
>> research to support it. But, Go designers themselves admit that this is an
>> issue and have written
>> tons on it.
>>
>
> You don't need a research or statistics if the complain is: "I don't want
> to write 'if err != nil { return err }' every single time".
>
> It means they use "if err := w.Close(); err != nil { return err }" for
> throwing the error, right? It is literally what they said or am I assuming?
>
> This same people will complain about your proposal, "I don't want to write
> 'orelse return err' every single time", and then we will add 'w.Close()!'
> or 'try w.Close()' to the language, and then we will be very happy with our
> Go++ wich has 3 ways of doing the same thing.
>
>
>> In one or two replies above we were discussing how error handling
>> opinions can become religions each with its own priests who think they are
>> the only saved faction, and that their rituals are the only right approach
>> for all situations.
>>
>
> I know, as I said, I like your proposal, but one of Go best features is
> the lack of new features. I am arguing against my own taste, because I like
> 'w.Close() or return fmt.Errorf("cannot close destination: %v", err)', but
> I like more the simplicity of Go.
>
>
>> Best wishes,
>>
>>
>> On Thursday, August 3, 2023 at 9:07:52 PM UTC-6 Miguel Angel Rivera
>> Notararigo wrote:
>>
>> func CopyFile(src, dst string) error {
>> r, err := os.Open(src)
>> if err != nil {
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>> defer r.Close()
>>
>> w, err := os.Create(dst)
>> if err != nil {
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>>
>> if _, err := io.Copy(w, r); err != nil {
>> w.Close()
>> os.Remove(dst)
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>>
>> if err := w.Close(); err != nil {
>> os.Remove(dst)
>> return fmt.Errorf("copy %s %s: %v", src, dst, err)
>> }
>> }
>>
>> I think it is a bad example, how do you know where CopyFile failed?
>>
>> The "copy ..." part shouldn't be in there, you should add valuable
>> context to your errors, if CopyFile fails, the caller already knows it was
>> a copy error because the function has a big "Copy" on his name right? you
>> should do this instead:
>>
>> func CopyFile(dst, src string) error {
>>   r, errOS := os.Open(src) // Avoid shadowing errors, don't use err
>>   if errOS != nil {
>> return fmt.Errorf("cannot open source: %v", errOS)
>>   }
>>
>>   defer r.Close()
>>
>>   w, errCD := os.Create(dst)
>>   if errCD != nil {
>> return fmt.Errorf("cannot create destination: %v", errCD)
>>   }
>>
>>   defer w.Close()
>>
>>   if _, err := io.Copy(w, r); err != nil { // Local scope error, so err
>> is fine
>> os.Remove(dst)
>> return fmt.Errorf("cannot copy data from source: %v", err)
>>
>>   }
>>
>>   if err := w.Close(); err != nil {
>> os.Remove(dst)
>> return fmt.Errorf("cannot close destination", err)
>>   }
>> }
>>
>> // Caller should do this.
>> if err := CopyFile("dst.txt", "src.txt"); err != nil {
>>   // Here is where you should add 'copy' to the error message.
>>   return fmt.Errorf("cannot copy '%s' to '%s': %v", src, dst, err)
>> }
>>
>> People complaining about Go's error handling regularly don't handle
>> errors, they just throw them like exceptions.
>>
>> If you really hate Go's error handling, just use:
>>
>> func catch(err error) {
>>   if 

Re: [go-nuts] Re: Error handling

[Miguel Angel Rivera Notararigo]

On Thu, Aug 3, 2023, 23:45 DrGo  wrote:

> @Miguel Angel Rivera Notararigo
>
> Thanks for taking the time to write...
>
> In my proposal, people are free to add as much context as they want...
>

Yeah I know, I like your proposal, it is just how they handle errors in the
V programming language, although they use the keyword "or" and have
Options/Results.

but as a demonstration, I am using the example from
> Ross Cox's paper on error handling that is used by all error handling
> proposals to show case their approach. I do not think Ross will
> take your criticism personally :)
>

I know, but just because he wrote that, doesn't mean it is the perfect
example. If I find myself writing code like that, I would probably hate
Go's error handling too, but that might be said for any other feature of
the language if I write some bad looking examples.

I don't see how he could take my opinion personally, I didn't mean to be
rude, I just said it is a bad example. I am not a native speaker, so my
apologies if I wrote something rude.

I on the other hand take exception to your generalization re people who
> complain about error handling in Go.
> I am sure you did not make that claim without having some sort of solid
> research to support it. But, Go designers themselves admit that this is an
> issue and have written
> tons on it.
>

You don't need a research or statistics if the complain is: "I don't want
to write 'if err != nil { return err }' every single time".

It means they use "if err := w.Close(); err != nil { return err }" for
throwing the error, right? It is literally what they said or am I assuming?

This same people will complain about your proposal, "I don't want to write
'orelse return err' every single time", and then we will add 'w.Close()!'
or 'try w.Close()' to the language, and then we will be very happy with our
Go++ wich has 3 ways of doing the same thing.


> In one or two replies above we were discussing how error handling opinions
> can become religions each with its own priests who think they are the only
> saved faction, and that their rituals are the only right approach for all
> situations.
>

I know, as I said, I like your proposal, but one of Go best features is the
lack of new features. I am arguing against my own taste, because I like
'w.Close() or return fmt.Errorf("cannot close destination: %v", err)', but
I like more the simplicity of Go.


> Best wishes,
>
>
> On Thursday, August 3, 2023 at 9:07:52 PM UTC-6 Miguel Angel Rivera
> Notararigo wrote:
>
> func CopyFile(src, dst string) error {
> r, err := os.Open(src)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> defer r.Close()
>
> w, err := os.Create(dst)
> if err != nil {
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if _, err := io.Copy(w, r); err != nil {
> w.Close()
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
>
> if err := w.Close(); err != nil {
> os.Remove(dst)
> return fmt.Errorf("copy %s %s: %v", src, dst, err)
> }
> }
>
> I think it is a bad example, how do you know where CopyFile failed?
>
> The "copy ..." part shouldn't be in there, you should add valuable context
> to your errors, if CopyFile fails, the caller already knows it was a copy
> error because the function has a big "Copy" on his name right? you should
> do this instead:
>
> func CopyFile(dst, src string) error {
>   r, errOS := os.Open(src) // Avoid shadowing errors, don't use err
>   if errOS != nil {
> return fmt.Errorf("cannot open source: %v", errOS)
>   }
>
>   defer r.Close()
>
>   w, errCD := os.Create(dst)
>   if errCD != nil {
> return fmt.Errorf("cannot create destination: %v", errCD)
>   }
>
>   defer w.Close()
>
>   if _, err := io.Copy(w, r); err != nil { // Local scope error, so err is
> fine
> os.Remove(dst)
> return fmt.Errorf("cannot copy data from source: %v", err)
>
>   }
>
>   if err := w.Close(); err != nil {
> os.Remove(dst)
> return fmt.Errorf("cannot close destination", err)
>   }
> }
>
> // Caller should do this.
> if err := CopyFile("dst.txt", "src.txt"); err != nil {
>   // Here is where you should add 'copy' to the error message.
>   return fmt.Errorf("cannot copy '%s' to '%s': %v", src, dst, err)
> }
>
> People complaining about Go's error handling regularly don't handle
> errors, they just throw them like exceptions.
>
> If you really hate Go's error handling, just use:
>
> func catch(err error) {
>   if err != nil {
> panic(err)
>   }
>
>   // And use recover somewhere
> }
>
> Which is a bad practice, but at least we (the people who like how Go
> handle errors) can still handle our errors without any language change.
>
> On Tue, Aug 1, 2023, 13:06 DrGo wrote:
>
> Thanks.
> The keystroke saving is not the motivation. The aim is to reduce the code
> reader’s mental load. My approach allows for clearer code where the main
> program logic is not dwarfed by the error handling code while maintaining
> the explicitly of error handling and 

[go-nuts] Re: How to convert an svg to a png (or gif) image?

[Brian Candler]

Also there's a project which compiles C code to Go - ISTR it was used to 
build a pure Go version of Sqlite.  Presumably the same approach could be 
applied to an image processing library.

https://twitter.com/bradfitz/status/855271867162083329?lang=en
https://groups.google.com/g/golang-nuts/c/QDEczMhlQBU/m/4lCn2kP0AwAJ
https://github.com/elliotchance/c2go

On Friday, 4 August 2023 at 11:58:19 UTC+1 Mandolyte wrote:

> and https://pkg.go.dev/github.com/canhlinh/svg2png
>
> On Friday, August 4, 2023 at 4:48:26 AM UTC-4 Mark wrote:
>
>> Thanks!
>>
>> On Friday, August 4, 2023 at 8:46:18 AM UTC+1 Tamás Gulácsi wrote:
>>
>>> https://pkg.go.dev/github.com/goki/gi/svg
>>>
>>> Mark a következőt írta (2023. augusztus 3., csütörtök, 13:18:48 UTC+2):
>>>
 I know this has been asked before, just wondered if there were any 
 pure-Go solutions?

>>>

-- 
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/c2523fb7-2308-4f77-ae60-56779c696402n%40googlegroups.com.

[go-nuts] Re: How to convert an svg to a png (or gif) image?

[Mandolyte]

and https://pkg.go.dev/github.com/canhlinh/svg2png

On Friday, August 4, 2023 at 4:48:26 AM UTC-4 Mark wrote:

> Thanks!
>
> On Friday, August 4, 2023 at 8:46:18 AM UTC+1 Tamás Gulácsi wrote:
>
>> https://pkg.go.dev/github.com/goki/gi/svg
>>
>> Mark a következőt írta (2023. augusztus 3., csütörtök, 13:18:48 UTC+2):
>>
>>> I know this has been asked before, just wondered if there were any 
>>> pure-Go solutions?
>>>
>>

-- 
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/eac3ed54-4972-4675-a515-d6741865b2c3n%40googlegroups.com.

[go-nuts] Re: How to convert an svg to a png (or gif) image?

['Mark' via golang-nuts]

Thanks!

On Friday, August 4, 2023 at 8:46:18 AM UTC+1 Tamás Gulácsi wrote:

> https://pkg.go.dev/github.com/goki/gi/svg
>
> Mark a következőt írta (2023. augusztus 3., csütörtök, 13:18:48 UTC+2):
>
>> I know this has been asked before, just wondered if there were any 
>> pure-Go solutions?
>>
>

-- 
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/6c0c3e50-72ab-42bb-9579-f8c9c967d5f5n%40googlegroups.com.

Re: [go-nuts] Realpath?

[TheDiveO]

Also, your function (as well as the one you seem to have copied and 
modified, did I get that right from your documentation?) will most probably 
not work correctly if there are symlinks "inside" the path and not just at 
the beginning of the given path. There's a reason to my limited 
understanding why the stdlib EvalSymlinks function has to iterate, in order 
to cover finding multiple symlinks along the path, and a previous symlink 
will influence later symlinks.

Some time ago, I had to get deeper into stdlib's EvalSymlinks in order to 
come up with a modified one that allows the path to be interpreted relative 
to an arbitrary other "root" path, even if the path to be resolved is 
seemingly absolute. It's a special use case when using Linux and doing 
funny mount namespace-related VFS accesses through Linux' process 
filesystem, and its "root" elements in particular. In case someone wants to 
know more, here we are: https://github.com/thediveo/procfsroot ... I'm 
using this to access the VFS view of containers without needing to spawn 
new processes, switching them into container mount namespaces, and then all 
the hassles of shuttling commands and responses forth and back. Instead, I 
resolve a path that is "absolute" to another mount namespace as relative to 
a suitable process filesystem entry and then can access the 
file/directory/etc. directly by the "resolved" path, using normal VFS 
syscalls from any arbitrary Go routine (and OS-level thread/task).
On Friday, August 4, 2023 at 10:14:18 AM UTC+2 TheDiveO wrote:

> As I couldn't figure this out from the repo's documentation: what's the 
> difference and what's the benefit compared to stdlib 
> https://pkg.go.dev/path/filepath#EvalSymlinks?
>
> On Thursday, August 3, 2023 at 8:57:08 PM UTC+2 Carlos Henrique Guardão 
> Gandarez wrote:
>
>> Hey there!
>>
>> I created a new lib to return a real path in Go.
>> https://github.com/gandarez/go-realpath
>>
>> Thanks.
>>
>> On Thursday, January 18, 2018 at 4:28:09 PM UTC-2 rgo...@redhat.com 
>> wrote:
>>
>>>
>>>
>>> On Monday, 16 July 2012 13:55:53 UTC+3, Rémy Oudompheng wrote:

 Did you have a look at filepath.EvalSymlinks? 

 Rémy. 

>>>
>>> Confirmed to be working. Thanks Remy. 
>>>
>>

-- 
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/4131ed67-d9cb-4755-90a6-96099d56f3d0n%40googlegroups.com.

Re: [go-nuts] Realpath?

[TheDiveO]

As I couldn't figure this out from the repo's documentation: what's the 
difference and what's the benefit compared to stdlib 
https://pkg.go.dev/path/filepath#EvalSymlinks?

On Thursday, August 3, 2023 at 8:57:08 PM UTC+2 Carlos Henrique Guardão 
Gandarez wrote:

> Hey there!
>
> I created a new lib to return a real path in Go.
> https://github.com/gandarez/go-realpath
>
> Thanks.
>
> On Thursday, January 18, 2018 at 4:28:09 PM UTC-2 rgo...@redhat.com wrote:
>
>>
>>
>> On Monday, 16 July 2012 13:55:53 UTC+3, Rémy Oudompheng wrote:
>>>
>>> Did you have a look at filepath.EvalSymlinks? 
>>>
>>> Rémy. 
>>>
>>
>> Confirmed to be working. Thanks Remy. 
>>
>

-- 
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/961d926b-62f8-42dc-9a97-13b5ae7b764dn%40googlegroups.com.

[go-nuts] Re: How to convert an svg to a png (or gif) image?

[Tamás Gulácsi]

https://pkg.go.dev/github.com/goki/gi/svg

Mark a következőt írta (2023. augusztus 3., csütörtök, 13:18:48 UTC+2):

> I know this has been asked before, just wondered if there were any pure-Go 
> solutions?
>

-- 
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/d65b7fcc-bfaa-4d29-9332-bfaf0c004bedn%40googlegroups.com.