Re: [go-nuts] How to cast a multi-value?

[Martin Leiser]

Assigning string values to string values or byte[] to byte[] does not 
require additional memory allocation.
But conversion between string and byte[] does so most of the time, because 
the underlying array of a string is immutable, versus the mutable of a 
byte[].

Encapsulating the type cast encapsulates exactly this potentially costly 
operation.
Whether this has a negativ or positive impact on potential compiler 
optimisation in respect to the need of a copy
in this special case, is hard to determine.

Amnon schrieb am Dienstag, 18. Mai 2021 um 22:09:18 UTC+2:

> My understanding was that a string had a pointer and a length,
> whereas a slice had a pointer and a length and a capacity.
>
> https://golang.org/src/reflect/value.go?s=59515:59567#L1973
>
>
> On Tuesday, 18 May 2021 at 20:32:39 UTC+1 Brian Candler wrote:
>
>> Assigning a string value to another variable doesn't double the memory 
>> usage.
>>
>> A value of type string consists of a pointer, a length, and a capacity, 
>> and only these are copied - so you get another copy of the pointer, 
>> pointing to the same data buffer.
>>
>>>

-- 
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/188a70df-4dff-40d7-a2d2-4ea64902aa28n%40googlegroups.com.

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

['Andrew G. Morgan' via golang-nuts]

This should be fully resolved at HEAD now.

On Friday, May 14, 2021 at 10:57:22 AM UTC-7 Andrew G. Morgan wrote:

>
> Indeed. I neglected to heed the comment I left expressly for this purpose. 
> :(
>
> Thanks!
>
> Andrew
>
> On Friday, May 14, 2021 at 10:25:18 AM UTC-7 ksri...@gmail.com wrote:
>
>> I applied your patch in-flight from your review, 
>> https://go-review.googlesource.com/c/go/+/319591/, 
>> and I am seeing other failures. It appears we need to apply the ordering 
>> of setgids to the following tests as well.
>>
>> Also, I grepped around for the pattern syscall.Setgroups there are no 
>> others I could see.
>>
>> Thanks
>> Kumar
>>
>>
>> % grep -i -r SetGroup misc/cgo/*
>> misc/cgo/test/issue1435.go: {call: 
>> "Setgroups([]int{0,1,2,3})", fn: func() error { return 
>> syscall.Setgroups([]int{0, 1, 2, 3}) }, filter: "Groups:", expect: "\t0 1 2 
>> 3"},
>> misc/cgo/test/issue1435.go: {call: "Setgroups(nil)", fn: 
>> func() error { return syscall.Setgroups(nil) }, filter: "Groups:", expect: 
>> ""},
>> misc/cgo/test/issue1435.go: {call: "Setgroups([]int{0})", fn: 
>> func() error { return syscall.Setgroups([]int{0}) }, filter: "Groups:", 
>> expect: "\t0"},
>>
>> # ../misc/cgo/test
>> --- FAIL: Test1435 (0.01s)
>> issue1435.go:181: [6] "Setgroups([]int{0,1,2,3})" comparison: 
>> "/proc/29462/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
>> [pid=29462 file:'Name: test.test
>> Umask: 0022
>> State: S (sleeping)
>> Tgid: 29462
>> Ngid: 0
>> Pid: 29462
>> PPid: 27896
>> TracerPid: 0
>> Uid: 0 0 0 0
>> Gid: 0 0 0 0
>> FDSize: 64
>> Groups: 1 2 3 0 
>> NStgid: 29462
>> NSpid: 29462
>> NSpgid: 9
>> NSsid: 9
>> VmPeak: 1215460 kB
>> VmSize: 1191416 kB
>> VmLck:   0 kB
>> VmPin:   0 kB
>> VmHWM:5848 kB
>> VmRSS:5848 kB
>> RssAnon:1724 kB
>> RssFile:4124 kB
>> RssShmem:   0 kB
>> VmData:  194472 kB
>> VmStk: 132 kB
>> VmExe:1580 kB
>> VmLib:1700 kB
>> VmPTE: 156 kB
>> VmSwap:   0 kB
>> HugetlbPages:   0 kB
>> CoreDumping: 0
>> Threads: 12
>> SigQ: 0/128577
>> SigPnd: 
>> ShdPnd: 
>> SigBlk: fffc3bfa3a00
>> SigIgn: 
>> SigCgt: fffdffc1feff
>> CapInh: a80425fb
>> CapPrm: a80425fb
>> CapEff: a80425fb
>> CapBnd: a80425fb
>> CapAmb: 
>> NoNewPrivs: 0
>> Seccomp: 2
>> Speculation_Store_Bypass: thread force mitigated
>> Cpus_allowed: ff
>> Cpus_allowed_list: 0-7
>> Mems_allowed: 
>> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
>> Mems_allowed_list: 0
>> voluntary_ctxt_switches: 19
>> nonvoluntary_ctxt_switches: 0
>> ' Pid: 29462]
>> FAIL
>> exit status 1
>> FAIL misc/cgo/test 6.853s
>> 2021/05/14 16:53:14 Failed: exit status 1
>> --- FAIL: Test1435 (0.01s)
>> issue1435.go:181: [6] "Setgroups([]int{0,1,2,3})" comparison: 
>> "/proc/29422/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
>> [pid=29422 file:'Name: test.test
>> Umask: 0022
>> State: S (sleeping)
>> Tgid: 29422
>> Ngid: 0
>> Pid: 29422
>> PPid: 27897
>> TracerPid: 0
>> Uid: 0 0 0 0
>> Gid: 0 0 0 0
>> FDSize: 64
>> Groups: 1 2 3 0 
>> NStgid: 29422
>> NSpid: 29422
>> NSpgid: 9
>> NSsid: 9
>> VmPeak: 1215712 kB
>> VmSize: 1192820 kB
>> VmLck:   0 kB
>> VmPin:   0 kB
>> VmHWM:5104 kB
>> VmRSS:5104 kB
>> RssAnon:1464 kB
>> RssFile:3640 kB
>> RssShmem:   0 kB
>> VmData:  195880 kB
>> VmStk: 132 kB
>> VmExe:1556 kB
>> VmLib:1728 kB
>> VmPTE: 176 kB
>> VmSwap:   0 kB
>> HugetlbPages:   0 kB
>> CoreDumping: 0
>> Threads: 12
>> SigQ: 0/128577
>> SigPnd: 
>> ShdPnd: 
>> SigBlk: fffc3bfa3a00
>> SigIgn: 
>> SigCgt: fffdffc1feff
>> CapInh: a80425fb
>> CapPrm: a80425fb
>> CapEff: a80425fb
>> CapBnd: a80425fb
>> CapAmb: 
>> NoNewPrivs: 0
>> Seccomp: 2
>>   

Re: [go-nuts] How to cast a multi-value?

[Amnon]

My understanding was that a string had a pointer and a length,
whereas a slice had a pointer and a length and a capacity.

https://golang.org/src/reflect/value.go?s=59515:59567#L1973


On Tuesday, 18 May 2021 at 20:32:39 UTC+1 Brian Candler wrote:

> Assigning a string value to another variable doesn't double the memory 
> usage.
>
> A value of type string consists of a pointer, a length, and a capacity, 
> and only these are copied - so you get another copy of the pointer, 
> pointing to the same data buffer.
>
>>

-- 
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/951b1505-e6d7-42d0-b78e-cea207956281n%40googlegroups.com.

Re: [go-nuts] How to cast a multi-value?

[Brian Candler]

Assigning a string value to another variable doesn't double the memory 
usage.

A value of type string consists of a pointer, a length, and a capacity, and 
only these are copied - so you get another copy of the pointer, pointing to 
the same data buffer.

>

-- 
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/4c6168df-c5f3-44cd-8191-e6ed4672cbben%40googlegroups.com.

Re: [go-nuts] How to cast a multi-value?

['Marc Michael' via golang-nuts]

'Keith Randall' via golang-nuts  schrieb am
Di., 18. Mai 2021, 18:25:

> You can use a function call to do the cast:
>
> func byteErr2stringErr(b []byte, e error) (string, error) {
> return string(b), e
> }
> content, err := byteErr2stringErr(os.ReadFile(path))
>
> It's still using additional variables, but they are hidden inside the
> helper function.
> On Sunday, May 16, 2021 at 8:07:24 PM UTC-7 Kurtis Rader wrote:
>
>> On Sun, May 16, 2021 at 7:49 PM 'Marc Michael' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> as Go provides multi values I would expect that's possible to cast such
>>> a multi value. Do I see it correctly, that Go does not provide it?
>>>
>>> Example:
>>>
>>> os.ReadFile returns []byte, error.
>>> I want to cast the []byte to a string.
>>>
>>> content, err := os.ReadFile(path)
>>>
>>> Is it possible to cast the []byte directly to a string without using a
>>> second variable?
>>>
>>
>> No, it is not possible to transform the type of one return value in a 
>> multi-valued
>> expression such as a function call. Such syntactic sugar would have limited
>> usefulness and, in my opinion, is likely to decrease readability and thus
>> be a source of bugs. If you find yourself needing to perform such
>> conversions so often that such a feature is useful that suggests the APIs
>> you're using need to be changed.
>>
>
Hello,

thanks for the clarification. I have thought that I had something overseen.

I have thought about introducing a second variable of type string, but this
would lead to doubling of the memory usage, especaly as I don't now really
how much data there is. With the additional function I think this would not
a real problem, as the []byte would go away if the additional function
finishes.

Thanks all for your help. :-)

Kindly regards

>

-- 
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/CAEOc3dUsahY7W3o_6j%3DM6ycRMnpv6XXnHOr0tyXxperzZ%3DB9kg%40mail.gmail.com.

Re: [go-nuts] How to cast a multi-value?

['Keith Randall' via golang-nuts]

You can use a function call to do the cast:

func byteErr2stringErr(b []byte, e error) (string, error) {
return string(b), e
}
content, err := byteErr2stringErr(os.ReadFile(path))

It's still using additional variables, but they are hidden inside the 
helper function.
On Sunday, May 16, 2021 at 8:07:24 PM UTC-7 Kurtis Rader wrote:

> On Sun, May 16, 2021 at 7:49 PM 'Marc Michael' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> as Go provides multi values I would expect that's possible to cast such a 
>> multi value. Do I see it correctly, that Go does not provide it?
>>
>> Example:
>>
>> os.ReadFile returns []byte, error. 
>> I want to cast the []byte to a string.
>>
>> content, err := os.ReadFile(path)
>>
>> Is it possible to cast the []byte directly to a string without using a 
>> second variable?
>>
>
> No, it is not possible to transform the type of one return value in a 
> multi-valued 
> expression such as a function call. Such syntactic sugar would have limited 
> usefulness and, in my opinion, is likely to decrease readability and thus 
> be a source of bugs. If you find yourself needing to perform such 
> conversions so often that such a feature is useful that suggests the APIs 
> you're using need to be changed.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/eca8c069-5537-43ae-969c-cb334b7d7484n%40googlegroups.com.

Re: [go-nuts] How can I check error types of gRPC calls?

['Axel Wagner' via golang-nuts]

*want, sorry, typo :)

On Tue, May 18, 2021 at 4:44 PM Axel Wagner 
wrote:

> You cant to use status.Code(err)
> , which gives you
> the gRPC status code.
>
>
> On Tue, May 18, 2021 at 3:08 PM cpu...@gmail.com 
> wrote:
>
>>
>> Thank you for the pointer. After looking at the API, I'm still confused
>> how to use it. I can status.Convert(err) to get a status object but
>> couldn't really figure how how to use that to extract the actual underlying
>> base error?
>> On Saturday, May 15, 2021 at 2:12:28 PM UTC+2 kortschak wrote:
>>
>>> On Sat, 2021-05-15 at 04:47 -0700, cpu...@gmail.com wrote:
>>> > In my local code, I'm using things like
>>> >
>>> > if errors.Is(err, api.ErrMustRetry) { ... }
>>> >
>>> > How would I achieve the same on errors returned by the gRCP
>>> > interface? I've noticed these are wrapped:
>>> >
>>> > rpc error: code = Unknown desc = must retry rpc error: code = Unknown
>>> > desc = must retry
>>> >
>>> > I assume the errors package won't work here as type information is
>>> > not carried across gRPC: What is the best practice here: unwrap the
>>> > root error from the RPC result (how) and perform string comparison?
>>> >
>>>
>>> There is the status package which provides tools for examining the gRPC
>>> errors, https://pkg.go.dev/google.golang.org/grpc/status.
>>>
>>>
>>> --
>> 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/8ecd4024-a846-4657-8e61-15c16289ccd2n%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/CAEkBMfEk%3DvhxW%2BY7MV0TdKX_pk6GCcDB7XNc9KTPQWyr_AZmdg%40mail.gmail.com.

Re: [go-nuts] How can I check error types of gRPC calls?

['Axel Wagner' via golang-nuts]

You cant to use status.Code(err)
, which gives you
the gRPC status code.


On Tue, May 18, 2021 at 3:08 PM cpu...@gmail.com  wrote:

>
> Thank you for the pointer. After looking at the API, I'm still confused
> how to use it. I can status.Convert(err) to get a status object but
> couldn't really figure how how to use that to extract the actual underlying
> base error?
> On Saturday, May 15, 2021 at 2:12:28 PM UTC+2 kortschak wrote:
>
>> On Sat, 2021-05-15 at 04:47 -0700, cpu...@gmail.com wrote:
>> > In my local code, I'm using things like
>> >
>> > if errors.Is(err, api.ErrMustRetry) { ... }
>> >
>> > How would I achieve the same on errors returned by the gRCP
>> > interface? I've noticed these are wrapped:
>> >
>> > rpc error: code = Unknown desc = must retry rpc error: code = Unknown
>> > desc = must retry
>> >
>> > I assume the errors package won't work here as type information is
>> > not carried across gRPC: What is the best practice here: unwrap the
>> > root error from the RPC result (how) and perform string comparison?
>> >
>>
>> There is the status package which provides tools for examining the gRPC
>> errors, https://pkg.go.dev/google.golang.org/grpc/status.
>>
>>
>> --
> 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/8ecd4024-a846-4657-8e61-15c16289ccd2n%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/CAEkBMfERsv28%2BJV-EVYqhZraHbyYmPftQV6V0i55zVaK1R13HQ%40mail.gmail.com.

[go-nuts] Re: Golang document scanning with TWAIN

[郑昕]

hi,Can you give me an example?

在2016年5月13日星期五 UTC+8 下午4:53:09 写道：

> Thank you a lot Egon :)
>
>
> On Thursday, 12 May 2016 07:49:10 UTC+2, Egon wrote:
>>
>> On Wednesday, 11 May 2016 16:43:29 UTC+3, dtr...@gmail.com wrote:
>>>
>>> Dear Gophers I'm an absolute begginner in Go. I do not grasp the CGO 
>>> completely
>>>
>>> I wanted to ask about TWAIN scanning in windows.
>>>
>>> TWAIN has a huge .h file ( 
>>> http://twain.org/docs/530fe0db85f7511c51000500/twain.zip )
>>> that can be found at 
>>> http://twain.org/scanner-application-developers/specification-and-tools.html
>>>
>>> Did someone implement support of TWAIN in a Win 386 system to give some 
>>> help or at least to give some directions in order me
>>> to start with this source code?
>>>
>>
>> Never seen one. 
>>
>> You won't need to convert the whole .h file, pick the minimal subset.
>>
>> 1. See how http://www.codeproject.com/Articles/296/A-C-Wrapper-for-TWAIN 
>> uses it and only convert those.
>> 2. Take a look how Go can use dll files (
>> https://github.com/golang/go/wiki/WindowsDLLs)
>> 3. Take a look at other bindings (should be plenty here 
>> https://github.com/golang/go/wiki/projects#windows)
>>
>> + Egon
>>
>

-- 
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/2844a793-1c42-4e8d-a27c-717593ec5589n%40googlegroups.com.

Re: [go-nuts] How can I check error types of gRPC calls?

[Brian Candler]

It's an alias 
 for 
this:
https://pkg.go.dev/google.golang.org/grpc/internal/status#Status
So it should have Code() and Detail() methods.

-- 
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/04b38691-532a-4cab-a3a6-48f3546c00e1n%40googlegroups.com.

Re: [go-nuts] gonum plot : font error

[Fred]

@Roland : I saw this change too,  removing the error variable fix the 
problem :) 

Le mardi 18 mai 2021 à 12:44:40 UTC+2, rol...@gmail.com a écrit :

> Hello,
>
> applying Carlas's solution I got a failure in line 20 since plot.New() 
> returns a pointer but no pointer, error pair.
>
> Only after changing usage of New() I got the scatter-demo running. May be 
> error message can be enhanced :-)
>
> scatter-demo]$ go build
>
> # scatter-demo
> ./main.go:20:9: assignment mismatch: 2 variables but plot.New returns 1 
> values
>
>  20 p := plot.New() 21 if p == nil { 22 panic("Plotter cannot 
> be created") 23 }
>
>
> BR,
> Roland
>
>
> Am Mo., 17. Mai 2021 um 16:38 Uhr schrieb Fred :
>
>> Thanks Carla and Sébastien for your quick answer !
>>
>> Carla your solution works, when I use modules I do not have font errors. 
>>
>> What is strange is that I was not using modules in any computer to try 
>> this example and it was working in one an not the other :) 
>>
>> Le lundi 17 mai 2021 à 15:10:55 UTC+2, Sebastien Binet a écrit :
>>
>>> Salut Fred, 
>>>
>>> On Mon May 17, 2021 at 14:11 CET, Fred wrote: 
>>> > Hi, 
>>> > I have 2 computers with Linux Manjaro and go version 1.16.3. 
>>> > The same scatter plot 
>>> >  
>>> works 
>>> > on 
>>> > one computer and produces on the other these already known errors : 
>>> >  
>>> > 
>>> > # gonum.org/v1/plot/text 
>>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:153:3: cannot use 
>>> > hdlr.Fonts.Lookup(rm, fnt.Size).Face (type *sfnt.Font) as type 
>>> > *truetype.Font in field value 
>>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:154:3: cannot use 
>>> > hdlr.Fonts.Lookup(rm, fnt.Size).Face (type *sfnt.Font) as type 
>>> > *truetype.Font in field value 
>>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:155:3: cannot use 
>>> > hdlr.Fonts.Lookup(it, fnt.Size).Face (type *sfnt.Font) as type 
>>> > *truetype.Font in field value 
>>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:156:3: cannot use 
>>> > hdlr.Fonts.Lookup(bf, fnt.Size).Face (type *sfnt.Font) as type 
>>> > *truetype.Font in field value 
>>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:157:3: cannot use 
>>> > hdlr.Fonts.Lookup(bfit, fnt.Size).Face (type *sfnt.Font) as type 
>>> > *truetype.Font in field value 
>>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:221:3: cannot use 
>>> > op.Glyph.Font (type *truetype.Font) as type *sfnt.Font in field value 
>>>
>>> this should indeed be fixed w/ gonum/pl...@v0.9.0. 
>>>
>>> > 
>>> > an update does not fix the error. 
>>> > 
>>> > go get -u gonum.org/v1/plot/... 
>>> > # cd /home/fred/GO/src/github.com/go-latex/latex; git pull --ff-only 
>>> > Votre information de configuration indique de fusionner avec la 
>>> > référence 
>>> > 'refs/heads/master' 
>>> > du serveur distant, mais cette référence n'a pas été récupérée. 
>>> > package github.com/go-latex/latex/drawtex: exit status 1 
>>>
>>> this error may come from the fact that go-latex/latex is now using 
>>> 'main' as its main branch in lieu of 'master'. 
>>>
>>> hth, 
>>> -s 
>>>
>> -- 
>> 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/efb3fb0c-cbeb-4815-a0d9-ee7a4b638ad8n%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/9a0b204c-d17b-47a3-a3b9-cad3dc91bbd0n%40googlegroups.com.

Re: [go-nuts] How can I check error types of gRPC calls?

[cpu...@gmail.com]

Thank you for the pointer. After looking at the API, I'm still confused how 
to use it. I can status.Convert(err) to get a status object but couldn't 
really figure how how to use that to extract the actual underlying base 
error?
On Saturday, May 15, 2021 at 2:12:28 PM UTC+2 kortschak wrote:

> On Sat, 2021-05-15 at 04:47 -0700, cpu...@gmail.com wrote:
> > In my local code, I'm using things like
> >
> > if errors.Is(err, api.ErrMustRetry) { ... }
> >
> > How would I achieve the same on errors returned by the gRCP
> > interface? I've noticed these are wrapped:
> >
> > rpc error: code = Unknown desc = must retry rpc error: code = Unknown
> > desc = must retry
> >
> > I assume the errors package won't work here as type information is
> > not carried across gRPC: What is the best practice here: unwrap the
> > root error from the RPC result (how) and perform string comparison?
> >
>
> There is the status package which provides tools for examining the gRPC
> errors, https://pkg.go.dev/google.golang.org/grpc/status.
>
>
>

-- 
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/8ecd4024-a846-4657-8e61-15c16289ccd2n%40googlegroups.com.

Re: [go-nuts] gonum plot : font error

[Roland Müller]

Hello,

applying Carlas's solution I got a failure in line 20 since plot.New()
returns a pointer but no pointer, error pair.

Only after changing usage of New() I got the scatter-demo running. May be
error message can be enhanced :-)

scatter-demo]$ go build

# scatter-demo
./main.go:20:9: assignment mismatch: 2 variables but plot.New returns 1
values

 20 p := plot.New() 21 if p == nil { 22 panic("Plotter
cannot be created") 23 }


BR,
Roland


Am Mo., 17. Mai 2021 um 16:38 Uhr schrieb Fred :

> Thanks Carla and Sébastien for your quick answer !
>
> Carla your solution works, when I use modules I do not have font errors.
>
> What is strange is that I was not using modules in any computer to try
> this example and it was working in one an not the other :)
>
> Le lundi 17 mai 2021 à 15:10:55 UTC+2, Sebastien Binet a écrit :
>
>> Salut Fred,
>>
>> On Mon May 17, 2021 at 14:11 CET, Fred wrote:
>> > Hi,
>> > I have 2 computers with Linux Manjaro and go version 1.16.3.
>> > The same scatter plot
>> > 
>> works
>> > on
>> > one computer and produces on the other these already known errors :
>> > 
>> >
>> > # gonum.org/v1/plot/text
>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:153:3: cannot use
>> > hdlr.Fonts.Lookup(rm, fnt.Size).Face (type *sfnt.Font) as type
>> > *truetype.Font in field value
>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:154:3: cannot use
>> > hdlr.Fonts.Lookup(rm, fnt.Size).Face (type *sfnt.Font) as type
>> > *truetype.Font in field value
>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:155:3: cannot use
>> > hdlr.Fonts.Lookup(it, fnt.Size).Face (type *sfnt.Font) as type
>> > *truetype.Font in field value
>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:156:3: cannot use
>> > hdlr.Fonts.Lookup(bf, fnt.Size).Face (type *sfnt.Font) as type
>> > *truetype.Font in field value
>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:157:3: cannot use
>> > hdlr.Fonts.Lookup(bfit, fnt.Size).Face (type *sfnt.Font) as type
>> > *truetype.Font in field value
>> > /home/fred/GO/src/gonum.org/v1/plot/text/latex.go:221:3: cannot use
>> > op.Glyph.Font (type *truetype.Font) as type *sfnt.Font in field value
>>
>> this should indeed be fixed w/ gonum/pl...@v0.9.0.
>>
>> >
>> > an update does not fix the error.
>> >
>> > go get -u gonum.org/v1/plot/...
>> > # cd /home/fred/GO/src/github.com/go-latex/latex; git pull --ff-only
>> > Votre information de configuration indique de fusionner avec la
>> > référence
>> > 'refs/heads/master'
>> > du serveur distant, mais cette référence n'a pas été récupérée.
>> > package github.com/go-latex/latex/drawtex: exit status 1
>>
>> this error may come from the fact that go-latex/latex is now using
>> 'main' as its main branch in lieu of 'master'.
>>
>> hth,
>> -s
>>
> --
> 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/efb3fb0c-cbeb-4815-a0d9-ee7a4b638ad8n%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/CA%2B8p0G04%2B_HsOaNtojqWsy8gLpQfFa%3DKe9%3DyZ_RRnAMOpBSLmg%40mail.gmail.com.