If the objections on the too magical handle part, why not cut that part and
retain the check part?
Most of the time the we just forward the error on to the next level anyway.
Handling error is rarely done and should be explicit.
I got better keyword for this: reterr
A portmanteau of return error.
That's right, I had modules enabled.
After moving the repo under go path src directory it worked fine.
echo $GOPATH
/Users/sidhesh/Development/gocode
~/Development/gocode/src/github.com/robaho/goanalyzer/cmd/goanalyzer$ go
build
~/Development/gocode/src/github.com/robaho/goanalyzer/cmd/goanalyzer$
Thanks !
On Sun, Aug 30, 2020 at 9:35 PM Siddhesh Divekar
wrote:
> That's right, I had modules enabled.
> After moving the repo under go path src directory it worked fine.
>
> echo $GOPATH
> /Users/sidhesh/Development/gocode
> ~/Development/gocode/src/github.com/robaho/goanalyzer/cmd/goanalyzer$
On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris wrote:
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handling abbreviation proposal is rejected. How about
> some simple syntactic sugar like this:
>
> rin Something()
>
> Which is just a sugar for:
>
> if err
Cause the objection for previous error handling is code coverage, the
solution is for code coverage tools to desugarize *rinn* syntax.
The objective to minimize error handling "noise" from human eyes.
On Monday, August 31, 2020 at 9:29:44 AM UTC+7 Zakaria bin Haris wrote:
> For completeness if
For completeness if the function is something like:
func x() (data *Data, err error) {
}
then *rinn* should be smart enough to assign error to err variable and just
do return instead return err
On Monday, August 31, 2020 at 9:19:48 AM UTC+7 Zakaria bin Haris wrote:
> Sorry, I mean return i
Sorry, I mean return if not nil, so it should be *rinn* or please find some
better keyword for this :^).
On Monday, August 31, 2020 at 9:15:31 AM UTC+7 Zakaria bin Haris wrote:
> Hi, gophers!
>
> Idk if this has been proposed or discussed before.
>
> Given the last error handling abbreviation pr
Hi, gophers!
Idk if this has been proposed or discussed before.
Given the last error handling abbreviation proposal is rejected. How about
some simple syntactic sugar like this:
*rin* Something()
Which is just a sugar for:
if err := Something(); err != nil {
return err
}
To make it
Tonight, I rebuilt and ran using Go 1.15 and it was fine (I cleared the entire
build cache using -a). Maybe you have modules enabled?
Here is the output:
GOROOT=/usr/local/Cellar/go/1.15/libexec #gosetup
GOPATH=/Users/robertengels/go #gosetup
/usr/local/Cellar/go/1.15/libexec/bin/go build -a -o
i watched a video of gopher-os and looked through it's github repository
for ways to extract the object files needed and tried his command as
follows, but i'm getting these errors which i can't resolve:
GOARCH=386 GOOS=linux go build -n 2>&1 | sed -e "1s|^|set -e\n|" -e
"1s|^|export GOOS=linux\
Sorry if this is a bit obvious. I did not dive into your code. But I did
notice that replacePositionalPlaceholders returns buf.String(). If you are
certain that this is where the memory 'leak' is originating, then the most
likely scenario is that the returned string is never being collected. Is
On Sun, Aug 30, 2020 at 8:25 AM Sarath Prabath Redlapalli Jaya
wrote:
>
> Hi, we've been observing high memory usage in the following code
> https://github.com/Masterminds/squirrel/blob/master/placeholder.go#L113
>
> We measured from pprof of heap
>
> (pprof) top20
>
> Showing nodes accounting for
On Sun, Aug 30, 2020 at 8:28 AM Sarath Prabath Redlapalli Jaya
wrote:
>
> The memory usage of containers are ever increasing and has grown from 100 MB
> to ~ 1 GB in couple of hours. Not able to understand where the gap is, even
> though the the builder is being reset. Would keeping a sync.Pool
On Sun, Aug 30, 2020 at 7:32 AM xie cui wrote:
>
> i am trying to understand code of cmd/link, i need to know where linker get
> instructions(text segment in executable file) from *o file, and where linker
> write the binary data (.text segment) to excutable file(in linux it 's a elf
> file).
The memory usage of containers are ever increasing and has grown from 100
MB to ~ 1 GB in couple of hours. Not able to understand where the gap is,
even though the the builder is being reset. Would keeping a sync.Pool of
builders help here?
Regards
On Sunday, August 30, 2020 at 8:55:15 PM UTC+
Hi, we've been observing high memory usage in the following code
https://github.com/Masterminds/squirrel/blob/master/placeholder.go#L113
We measured from pprof of heap
(pprof) top20
Showing nodes accounting for 360.07MB, 91.31% of 394.32MB total
Dropped 142 nodes (cum <= 1.97MB)
Showing top 20
i am trying to understand code of cmd/link, i need to know where linker
get instructions(text segment in executable file) from *o file, and where
linker write the binary data (.text segment) to excutable file(in linux it
's a elf file).
--
You received this message because you are subscribed
Thank you, it worked, everything is automatic in Go when you come from Rust
and Java, Thank you again
On Sun, Aug 30, 2020 at 2:59 AM Bakul Shah wrote:
> Unless there is a very strong reason to use a doubly linked list, you
> should just use a slice:
>
> type Persons struct { name string; Names
18 matches
Mail list logo