[go-nuts] Re: gopls: How to suppress a warning?
Hallöchen! 'Robert Findley' via golang-nuts writes: > You can disable the "composites" analyzer: https://github.com/golang/ > tools/blob/master/gopls/doc/analyzers.md#composites > > Update the "analyses" configuration to include "composites": false, > as described here: https://github.com/golang/tools/blob/master/gopls/ > doc/settings.md#analyses-mapstringbool Thank you, this worked! Regards, Torsten. -- Torsten Bronger -- 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/87cz8azggw.fsf%40physik.rwth-aachen.de.
[go-nuts] Re: What are the best practices to write test-cases?
Testing style will tend to be shaped by both personal preference and the
needs of the project.
Personally, I do a ton of data-driven tests, as is required by my
data intensive projects (custom databases; analytics on them).
I often use a fork of goconvey for my testing. It promotes BDD
style of documenting your tests, which is
very helpful when revisiting them months or years later.
You state the intent of the test in a string
that is passed into the test framework. The
typical "Given... when... then..." style is useful.
https://github.com/smartystreets/goconvey
For tests of a database, I tend prefer to write both
my test output and my expected output to a file.
This keeps the expected output independent of
the code. Since the output of the database may
change dramatically (and then thousands of lines
of output may change due to a small code change),
this makes it very easy to update the expected correct
output when making a change to the processing pipeline.
If the expected output was hardcoded in the test code,
updating tests when the correct output
changes alot would be excruciating. By using files
to store the thousands of lines of output,
updating tests when the expected output changes is
very easy. Just copy over the new
output to the expected file, and done. Standard command
line tools like diff, head, and tail
make it easy to compare observed and expected
output of the test. I wrote a simple
test function to compare the two files
on disk. I'll copy it below. Expected output files
are version controlled, just like the test code.
This is also addresses a major pain point of doing the
extensive testing need to develop
working software. If you code the expected
value into your tests, they become alot of
work to update when the expected values change.
Have you ever broken 500 tests with one code change?
I certainly have. With expected on disk, its all
updated with a short bash script.
Obviously this is perhaps an unusual approach. Certainly
developers unfamiliar with
it may have a knee jerk reaction calling it
outrageous. Yet, it is extremely effective and efficient
for my projects.
Hopefully this example gives you a sense of why the
best practice is very dependent on the
project at hand.
It is worth being familiar with table driven tests as well.
// CompareFiles runs diff on the two given files, and returns the length of
the diff output.
func CompareFiles(expected string, observed string) (int, []byte) {
cmd := exec.Command("/usr/bin/diff", "-b", observed, expected)
var out bytes.Buffer
cmd.Stdout = &out
err := cmd.Run()
if err != nil {
fmt.Printf("CompareFiles(): error during '\ndiff %s %s\n': %s",
observed, expected, err)
return -1, nil // unknown, but not 0
}
N := len(out.Bytes())
return N, out.Bytes()
}
On Thursday, December 22, 2022 at 3:57:51 PM UTC-6 nishant...@keploy.io
wrote:
> Hi everyone!
> I am new to Golang and currently trying to research about Golang and what
> are the best practices for writing test-cases in Golang.
> While I have been able to find some resources online, I still have a doubt
> that I hope you can help me with. My doubt is related to the best practices
> for writing test-cases in Golang. Would love to know what practices fellow
> Golang devs follows.
> Thank you in advance for your help.
>
--
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/b507125a-b22a-4bb6-9992-4b2535c892f3n%40googlegroups.com.
[go-nuts] Re: Hide Golang Code from Exported package
I've made Windows DLLs work with Go, so I can be done, but I would strongly suggest that you avoid it. Windows applications expect to be able to unload their DLLs, and you can never do that with Go. There are work arounds, (search this form for my previous posts), but they are ugly and fragile. So, to save you alot of pain, I would advise you to use a server process as Brian suggests. You can provide in your SDK code wrapper methods that can, behind the scene if need be, start, stop, and makes RPC calls to that service to serve client requests. If need be, then the server could eventually remote, or shared over the network. If that doesn't work, I would just provide the source code to everything. On Wednesday, December 14, 2022 at 8:24:19 AM UTC-6 nsing...@gmail.com wrote: > Hi is there another way as we have to package it as a dll or a lib . > But whenever we try using syscall with dll it fails with "bad sweepgen in > refill" > Is there any other way where we font create a new executable > thanks > > On Monday, December 12, 2022 at 1:34:23 PM UTC+5:30 Brian Candler wrote: > >> Distribute your library as a grpc server. >> https://github.com/hashicorp/go-plugin >> >> On Monday, 12 December 2022 at 07:56:52 UTC nsing...@gmail.com wrote: >> >>> Actually i need to share it as an sdk. So any way i can share >>> >>> On Thursday, December 8, 2022 at 1:13:17 PM UTC+5:30 marc...@gmail.com >>> wrote: >>> if you produce an executable, nobody sees the actual Go code. build it with: go build -ldflags "-s -w" or you could try to obfuscate it: https://github.com/burrowers/garble or you can make a self-extracting executable Op woensdag 7 december 2022 om 19:09:31 UTC+1 schreef nsing...@gmail.com: > Hi All, > We are looking for a way to distribute a Golang Package. but We ant to > hide the Code which we have written. > We went Through Creating A DLL to distribute but it crashes at > different point while running. As we have distribute to Both linux and > windows . And i found that for linux we can use plugin. But the crash for > windows dll after importing the file is concerning for us and its > happening at random points in the code also "bad sweepgen in refill". > If there is any other way to distribute the code without showing the > source code please Tell > Thanks > Neeraj > -- 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/3830515e-1358-46ad-88d3-087b29b8fa54n%40googlegroups.com.
[go-nuts] js.ValueOf for an error
Hello everyone!
First, thank you *all* (I mean this great community) for the Go language
and especially its support for a wasm target.
As I was attempting to finish up a CL
(https://go-review.googlesource.com/c/go/+/458395) I found occasion to need
to great a JS Error based on a Go error. I was hoping to use the JS Error
constructor that includes an option object to specify a cause and value
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause)
by using the actual go error. Here's what I was thinking:
readErrCause := js.Global().Get("Object").New()
readErrCause.Set("code", readErr.Error())
readErrCause.Set("value", js.ValueOf(readErr))
readErr := js.Global().Get("Error").New("ReadFull failed", readErrCause)
(where readErr is of the `error` type, of course)
Unfortunately,
readErrCause.Set("value", js.ValueOf(readErr))
does not work because, as the comment so perfectly says, ValueOf
// Panics if x is not one of the expected types.
I am absolutely up for proposing and implementing a small addition to the
"js package" if people think it would be helpful but I wanted to check here
first.
Again, thank you for all the great work that you *all* do!!
Sincerely,
Will
--
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/c2e513e7-e2de-489b-902b-185a8b1ec2dcn%40googlegroups.com.
[go-nuts] Re: js.ValueOf for an error
I don't know how a raw Go interface value would be usable in Javascript.
As an alternative, would it be any good to use sprintf("%T", readErr) as
the code, and readErr.Error() as the value? At least those are both strings.
https://go.dev/play/p/nd1FXUvD_zg
On Friday, 23 December 2022 at 14:33:21 UTC Will Hawkins wrote:
> Hello everyone!
>
> First, thank you *all* (I mean this great community) for the Go language
> and especially its support for a wasm target.
>
> As I was attempting to finish up a CL (
> https://go-review.googlesource.com/c/go/+/458395) I found occasion to
> need to great a JS Error based on a Go error. I was hoping to use the JS
> Error constructor that includes an option object to specify a cause and
> value (
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause)
>
> by using the actual go error. Here's what I was thinking:
>
> readErrCause := js.Global().Get("Object").New()
> readErrCause.Set("code", readErr.Error())
> readErrCause.Set("value", js.ValueOf(readErr))
> readErr := js.Global().Get("Error").New("ReadFull failed", readErrCause)
>
> (where readErr is of the `error` type, of course)
>
> Unfortunately,
> readErrCause.Set("value", js.ValueOf(readErr))
>
> does not work because, as the comment so perfectly says, ValueOf
>
> // Panics if x is not one of the expected types.
>
> I am absolutely up for proposing and implementing a small addition to the
> "js package" if people think it would be helpful but I wanted to check here
> first.
>
> Again, thank you for all the great work that you *all* do!!
>
> Sincerely,
> Will
>
>
>
>
--
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/08d9eb2b-49bb-4a8a-8b81-d54b70a24fc0n%40googlegroups.com.
Re: [go-nuts] Re: js.ValueOf for an error
I agree. That is what I settled on, basically. Thanks for the suggestion!
Will
On Fri, Dec 23, 2022 at 10:23 AM Brian Candler wrote:
>
> I don't know how a raw Go interface value would be usable in Javascript. As
> an alternative, would it be any good to use sprintf("%T", readErr) as the
> code, and readErr.Error() as the value? At least those are both strings.
>
> https://go.dev/play/p/nd1FXUvD_zg
>
> On Friday, 23 December 2022 at 14:33:21 UTC Will Hawkins wrote:
>>
>> Hello everyone!
>>
>> First, thank you *all* (I mean this great community) for the Go language and
>> especially its support for a wasm target.
>>
>> As I was attempting to finish up a CL
>> (https://go-review.googlesource.com/c/go/+/458395) I found occasion to need
>> to great a JS Error based on a Go error. I was hoping to use the JS Error
>> constructor that includes an option object to specify a cause and value
>> (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause)
>> by using the actual go error. Here's what I was thinking:
>>
>> readErrCause := js.Global().Get("Object").New()
>> readErrCause.Set("code", readErr.Error())
>> readErrCause.Set("value", js.ValueOf(readErr))
>> readErr := js.Global().Get("Error").New("ReadFull failed", readErrCause)
>>
>> (where readErr is of the `error` type, of course)
>>
>> Unfortunately,
>> readErrCause.Set("value", js.ValueOf(readErr))
>>
>> does not work because, as the comment so perfectly says, ValueOf
>>
>> // Panics if x is not one of the expected types.
>>
>> I am absolutely up for proposing and implementing a small addition to the
>> "js package" if people think it would be helpful but I wanted to check here
>> first.
>>
>> Again, thank you for all the great work that you *all* do!!
>>
>> Sincerely,
>> Will
>>
>>
>>
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/zwwA1wRjA58/unsubscribe.
> To unsubscribe from this group and all its topics, 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/08d9eb2b-49bb-4a8a-8b81-d54b70a24fc0n%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/CADx9qWjfhro4E1vPpOfVVgg4FOmM1X8U2SuFf_izOhFTw4VzSg%40mail.gmail.com.
