[go-nuts] A team using Go won ISUCON10

[mattn]

As usual on the each years, in this year too, many Japanese web developers 
attended on ISUCON (an event to improve the HTTP server in a good fast). 
And in this year most of developers choiced Go.

# Preliminary stage (language, teams, ratio)
Go  328 62.2%
Ruby59  11.2%
Python  47   8.9%
Nodejs  42   8.0%
Rust24   4.6%
PHP 20   3.8%
Perl 7   1.3%

# Final stage
Go  27  90.0%
Rust 2   6.7%
Nodejs   1   3.3%

FYI, Below is languages that was used by Winner for each holds.
2011 ISUCON1 Perl
2012 ISUCON2 Perl
2013 ISUCON3 Perl
2014 ISUCON4 Perl
2015 ISUCON5 Perl
2016 ISUCON6 Go
2017 ISUCON7 Go
2018 ISUCON8 Go
2019 ISUCON9 Ruby
2021 ISOCON10 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/96cb63c0-56d3-4678-aa38-f1ac9e8b7e27n%40googlegroups.com.

[go-nuts] gollvm for LLVM13

[Khanh TN]

Hi,
While running the latest commit of gollvm (with latest commit of 
gofrontend, libbacktrace, libffi) with LLVM13 (commit llvmorg-13.0.0-rc3), 
I encountered this error:  

llvm-project/build13/tools/gollvm/libgo/version.go:9:6: error: redefinition 
of 'ArchFamilyType'
llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/internal/sys/arch.go:17:7:
 
note: previous definition of 'ArchFamily' was here


Is there a version that works with LLVM13 (preferably llvmorg-13.0.0-rc3)?

Thanks!

Khanh

-- 
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/846afef0-fd26-4eb2-aa36-90b6ccbdbb7bn%40googlegroups.com.

[go-nuts] gollvm for LLVM13

[Khanh TN]

Hi,
While running the latest commit of gollvm (with latest commit of 
gofrontend, libbacktrace, libffi) with LLVM13, I encountered this error:

llvm-project/build13/tools/gollvm/libgo/version.go:9:6: error: redefinition 
of 'ArchFamilyType'
llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/runtime/internal/sys/arch.go:7:6:
 
note: previous definition of 'ArchFamilyType' was here

and there are a few other errors.

Is there any version that I can run with LLVM13 (preferably commit 
llvmorg-13.0.0-rc1 or rc3)?

Thanks!

Khanh

-- 
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/de5d7eff-9fef-45b4-9a3f-b096ec2211c9n%40googlegroups.com.

Re: [go-nuts] how atomic instruction work?

['Dan Kortschak' via golang-nuts]

Also, https://research.swtch.com/mm.

On Tue, 2021-09-21 at 16:22 -0500, robert engels wrote:
> This may be of interest to you:
> https://github.com/golang/go/issues/5045
>
> > On Sep 21, 2021, at 4:17 PM, Ian Lance Taylor 
> > wrote:
> >
> > On Tue, Sep 21, 2021 at 12:54 PM xie cui 
> > wrote:
> > >
> > >
https://stackoverflow.com/questions/2599238/are-memory-barriers-necessary-for-atomic-reference-counting-shared-immutable-dat
> > > this answer say that:
> > > On x86, it will turn into a lock prefixed assembly instruction,
> > > like LOCK XADD.
> > > Being a single instruction, it is non-interruptible. As an added
> > > "feature", the lock prefix results in a full memory barrier.
> > >
> > > In my opinion, full memory barrier means flush store buffer and
> > > invalid queue(not very sure, is this right?)
> >
> > Can you be specific about exactly what you are asking?  You
> > originally
> > said "atomic instruction," and my answer was based on the functions
> > sync/atomic.LoadInt32 and sync/atomic.StoreInt32.  Here you seem to
> > be
> > talking about sync/atomic.AddInt32, which is fine, but let's agree
> > on
> > what the question is.  This is a Go language mailing list, so can
> > you
> > ask your question about a Go function, rather than about an "atomic
> > instruction"?  Thanks.
> >
> > Ian
> >
> >
> > > On Saturday, September 18, 2021 at 3:17:26 AM UTC+8 Ian Lance
> > > Taylor wrote:
> > > > On Fri, Sep 17, 2021 at 6:25 AM xie cui 
> > > > wrote:
> > > > > how atomic insturction work in golang at x86/amd64,
> > > > > I think the atomic insturtion will flush the store buffer and
> > > > > invalid queue of current cpu core,
> > > > > but I am not sure, does someone know about it?
> > > >
> > > > I assume that you are asking about the sync/atomic package. The
> > > > functions in that package will ensure sequential consistency of
> > > > atomic
> > > > operationns, but they will not flush the store buffer. See
> > > > https://research.swtch.com/gomm .
> > > >
> > > > 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/701c528b93cbaf7c5519e4831473195ebb8c7604.camel%40kortschak.io.

Re: [go-nuts] how atomic instruction work?

[robert engels]

This may be of interest to you: https://github.com/golang/go/issues/5045

> On Sep 21, 2021, at 4:17 PM, Ian Lance Taylor  wrote:
> 
> On Tue, Sep 21, 2021 at 12:54 PM xie cui  > wrote:
>> 
>> 
>> https://stackoverflow.com/questions/2599238/are-memory-barriers-necessary-for-atomic-reference-counting-shared-immutable-dat
>> this answer say that:
>> On x86, it will turn into a lock prefixed assembly instruction, like LOCK 
>> XADD.
>> Being a single instruction, it is non-interruptible. As an added "feature", 
>> the lock prefix results in a full memory barrier.
>> 
>> In my opinion, full memory barrier means flush store buffer and invalid 
>> queue(not very sure, is this right?)
> 
> Can you be specific about exactly what you are asking?  You originally
> said "atomic instruction," and my answer was based on the functions
> sync/atomic.LoadInt32 and sync/atomic.StoreInt32.  Here you seem to be
> talking about sync/atomic.AddInt32, which is fine, but let's agree on
> what the question is.  This is a Go language mailing list, so can you
> ask your question about a Go function, rather than about an "atomic
> instruction"?  Thanks.
> 
> Ian
> 
> 
>> On Saturday, September 18, 2021 at 3:17:26 AM UTC+8 Ian Lance Taylor wrote:
>>> 
>>> On Fri, Sep 17, 2021 at 6:25 AM xie cui  wrote:
 
 how atomic insturction work in golang at x86/amd64,
 I think the atomic insturtion will flush the store buffer and invalid 
 queue of current cpu core,
 but I am not sure, does someone know about it?
>>> 
>>> I assume that you are asking about the sync/atomic package. The
>>> functions in that package will ensure sequential consistency of atomic
>>> operationns, but they will not flush the store buffer. See
>>> https://research.swtch.com/gomm .
>>> 
>>> 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/aa7487d1-13f1-451b-86a3-f7f70a7c040cn%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/CAOyqgcX-12SQkcow1az%2BPhOYfubvmuD0q72yOc_xOo%3Dia2J_SQ%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/7A0E5DBB-57FB-45AD-88AE-DC06C94DA15A%40ix.netcom.com.

Re: [go-nuts] how atomic instruction work?

[Ian Lance Taylor]

On Tue, Sep 21, 2021 at 12:54 PM xie cui  wrote:
>
>
> https://stackoverflow.com/questions/2599238/are-memory-barriers-necessary-for-atomic-reference-counting-shared-immutable-dat
> this answer say that:
> On x86, it will turn into a lock prefixed assembly instruction, like LOCK 
> XADD.
> Being a single instruction, it is non-interruptible. As an added "feature", 
> the lock prefix results in a full memory barrier.
>
> In my opinion, full memory barrier means flush store buffer and invalid 
> queue(not very sure, is this right?)

Can you be specific about exactly what you are asking?  You originally
said "atomic instruction," and my answer was based on the functions
sync/atomic.LoadInt32 and sync/atomic.StoreInt32.  Here you seem to be
talking about sync/atomic.AddInt32, which is fine, but let's agree on
what the question is.  This is a Go language mailing list, so can you
ask your question about a Go function, rather than about an "atomic
instruction"?  Thanks.

Ian


> On Saturday, September 18, 2021 at 3:17:26 AM UTC+8 Ian Lance Taylor wrote:
>>
>> On Fri, Sep 17, 2021 at 6:25 AM xie cui  wrote:
>> >
>> > how atomic insturction work in golang at x86/amd64,
>> > I think the atomic insturtion will flush the store buffer and invalid 
>> > queue of current cpu core,
>> > but I am not sure, does someone know about it?
>>
>> I assume that you are asking about the sync/atomic package. The
>> functions in that package will ensure sequential consistency of atomic
>> operationns, but they will not flush the store buffer. See
>> https://research.swtch.com/gomm .
>>
>> 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/aa7487d1-13f1-451b-86a3-f7f70a7c040cn%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/CAOyqgcX-12SQkcow1az%2BPhOYfubvmuD0q72yOc_xOo%3Dia2J_SQ%40mail.gmail.com.

[go-nuts] Generic error handling with panic, recover, and defer

[Marcos César de Oliveira]

With go 1.18 generics implementation it is now possible to provide error 
handling functions in a fashion similar to the "try" proposal. I wrote a 
small library that implements this approach: https://github.com/mcesar/must.

An example of usage is as follows:

package main
import (
"fmt"
"os"
"github.com/mcesar/must"
)
func main() {
fmt.Println(f())
}
func f() (err error) {
defer must.Handle()
f := must.Do(os.Open("file"))
defer f.Close()
// ...
return nil
}

This idea is not new, but I think it is worthwhile to have an 
implementation to experiment with.

-- 
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/4950bb51-f607-4157-b448-fccacf344d27n%40googlegroups.com.

[go-nuts] Re: What is up with memo.com?

[Brian Candler]

I've seen the same too.  Sadly memo.com don't provide any opt-out link in 
their messages.

Based on IP addresses in headers, the parent appears to 
be https://joylabs.com/.  I tried contacting them via their web contact 
form, but have had no response.
 
On Tuesday, 21 September 2021 at 17:48:20 UTC+1 peterGo wrote:

> Ian,
>
> I received some gmail from memo.com for a golang-nuts conversation that I 
> participated in. I marked the gmail messages as spam.
>
> Peter
>
> On Tuesday, September 21, 2021 at 12:11:31 PM UTC-4 Ian Lance Taylor wrote:
>
>> I'm seeing random repeats of golang-nuts messages sent from memo.com
>> with bad formatting. I'm also seeing regular messages telling me that
>> someone has connected with golang-nuts on memo.com, which I've been
>> rejecting at the moderation stage.
>>
>> Does anybody know what is going on? I don't want to start marking all
>> these messages as spam if they are useful in some way, but so far I
>> don't see it.
>>
>> Thanks.
>>
>> 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/9f2383db-438a-4d31-8fca-52a2198abf9cn%40googlegroups.com.

Re: [go-nuts] how atomic instruction work?

[xie cui]

https://stackoverflow.com/questions/2599238/are-memory-barriers-necessary-for-atomic-reference-counting-shared-immutable-dat
this answer say that:
On x86, it will turn into a lock prefixed assembly instruction, like LOCK 
XADD.
Being a single instruction, it is non-interruptible. As an added "feature", 
the lock prefix results in a full memory barrier.

In my opinion, full memory barrier means flush store buffer and invalid 
queue(not very sure, is this right?)
On Saturday, September 18, 2021 at 3:17:26 AM UTC+8 Ian Lance Taylor wrote:

> On Fri, Sep 17, 2021 at 6:25 AM xie cui  wrote:
> >
> > how atomic insturction work in golang at x86/amd64,
> > I think the atomic insturtion will flush the store buffer and invalid 
> queue of current cpu core,
> > but I am not sure, does someone know about it?
>
> I assume that you are asking about the sync/atomic package. The
> functions in that package will ensure sequential consistency of atomic
> operationns, but they will not flush the store buffer. See
> https://research.swtch.com/gomm .
>
> 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/aa7487d1-13f1-451b-86a3-f7f70a7c040cn%40googlegroups.com.

Re: [go-nuts] What is the total max size of embed content?

[Glen Newton]

Hello Ian,

Yes, I think it is time I explain the 'why' of my inquiries into this. :-)

My use case is this: Go, with its fast startup, pretty fast execution and 
pretty small memory footprint, as well as it's ability to deploy as a 
single binary, makes it a great language for cloud function-as-a-service 
(FAAS). 

My specific FAAS use case is for static, read-only databases: I am looking 
at embedding modest sized (few GB to 10s of GB) read-only databases in the 
Go binary. 

This makes it possible to avoid the cost/complication of either using a 
cloud db, or storing the db in (in the case of AWS) on a file system like 
EFS (NFS), which the lambda has to mount. The databases are only updated 
every couple of months / yearly.
This is perhaps rather an obscure use case, but one that I think a number 
of people would want to take advantage of.

>Note that such files are going to take a long time to create and will be 
unwieldy to use.
Agreed. On my older desktop (Dell 7010 Kubuntu 20.10 4core i5 16GM) it 
takes 45s to compile a trivial Go program that embeds three 500GB files.

Actually, this is no different from those who want the simplicity and cost 
savings of serving an entire static web site from embedded files. The 
primary difference is the scale.

Thanks,
Glen


On Tuesday, September 21, 2021 at 1:28:12 PM UTC-4 Ian Lance Taylor wrote:

> On Tue, Sep 21, 2021 at 6:23 AM Glen Newton  wrote:
> >
> > Looking at https://groups.google.com/g/golang-codereviews/c/xkHLQHidF5s 
> and https://github.com/golang/go/issues/9862 and the code to which they 
> refer, it seems to me that the limit is 2GB independent of platform (is 
> this true?), as the linker is limited to 2e9.
> > Again, should have done more of my homework! :-)
> >
> > 
> https://github.com/golang/go/blob/master/src/cmd/internal/obj/objfile.go#L305
> >
> > // cutoff is the maximum data section size permitted by the linker
> > // (see issue #9862). const cutoff = 2e9 // 2 GB (or so; looks better in 
> errors than 2^31)
> > const cutoff = 2e9 // 2 GB (or so; looks better in errors than 2^31)
> >
> > The comment indicates that this is a limit in the linker; is this a 
> limit in the elf format? If No, could the linker et al be modified to 
> accept larger static data?
>
> You're right: it does look like cmd/link imposes a 2G total limit.
> This is not a limitation of the 64-bit ELF format. It should be
> possible to make it larger.
>
> Note that such files are going to take a long time to create and will
> be unwieldy to use. While it should be possible to increase the size,
> I would not be surprised if you hit other limits fairly quickly.
>
> 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/9aee61f1-be26-45a8-96f6-b06ff65983ban%40googlegroups.com.

Re: [go-nuts] What is the total max size of embed content?

[Ian Lance Taylor]

On Tue, Sep 21, 2021 at 6:23 AM Glen Newton  wrote:
>
> Looking at https://groups.google.com/g/golang-codereviews/c/xkHLQHidF5s and 
> https://github.com/golang/go/issues/9862 and the code to which they refer, it 
> seems to me that the limit is 2GB independent of platform (is this true?), as 
> the linker is limited to 2e9.
> Again, should have done more of my homework!  :-)
>
> https://github.com/golang/go/blob/master/src/cmd/internal/obj/objfile.go#L305
>
> // cutoff is the maximum data section size permitted by the linker
> // (see issue #9862). const cutoff = 2e9 // 2 GB (or so; looks better in 
> errors than 2^31)
> const cutoff = 2e9 // 2 GB (or so; looks better in errors than 2^31)
>
> The comment indicates that this is a limit in the linker; is this a limit in 
> the elf format? If No, could the linker et al be modified to accept larger 
> static data?

You're right: it does look like cmd/link imposes a 2G total limit.
This is not a limitation of the 64-bit ELF format.  It should be
possible to make it larger.

Note that such files are going to take a long time to create and will
be unwieldy to use.  While it should be possible to increase the size,
I would not be surprised if you hit other limits fairly quickly.

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

[go-nuts] Re: What is up with memo.com?

[peterGo]

Ian,

I received some gmail from memo.com for a golang-nuts conversation that I 
participated in. I marked the gmail messages as spam.

Peter

On Tuesday, September 21, 2021 at 12:11:31 PM UTC-4 Ian Lance Taylor wrote:

> I'm seeing random repeats of golang-nuts messages sent from memo.com
> with bad formatting. I'm also seeing regular messages telling me that
> someone has connected with golang-nuts on memo.com, which I've been
> rejecting at the moderation stage.
>
> Does anybody know what is going on? I don't want to start marking all
> these messages as spam if they are useful in some way, but so far I
> don't see it.
>
> Thanks.
>
> 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/c0d397c2-f22f-4cc4-80a5-df4836ff9dd8n%40googlegroups.com.

[go-nuts] What is up with memo.com?

[Ian Lance Taylor]

I'm seeing random repeats of golang-nuts messages sent from memo.com
with bad formatting.  I'm also seeing regular messages telling me that
someone has connected with golang-nuts on memo.com, which I've been
rejecting at the moderation stage.

Does anybody know what is going on?  I don't want to start marking all
these messages as spam if they are useful in some way, but so far I
don't see it.

Thanks.

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/CAOyqgcXOLPKuHxPoh8JX7-Azj4UKf%2BFTKriEvEGur3Dk4r2epg%40mail.gmail.com.

Re: [go-nuts] Idea extending xerror.As

[David Finkel]

On Mon, Sep 20, 2021 at 10:52 PM Andrey T. 
wrote:

>
> ... or, to put a crazy idea out there, we need to ask for extension of
> switch statement to support (v, err) tuples for a case argument...


That's not a particularly crazy idea. It's just one that's unlikely to make
it through with one use-case like this since the bar for language changes
is so much higher than standard library changes. (for good reason)

On Sunday, September 19, 2021 at 3:43:36 PM UTC-6 david@gmail.com wrote:
>
>> On Sun, Sep 19, 2021 at 5:19 PM roger peppe  wrote:
>>
>>> In some ways, the existing API is arguably more ergonomic than the
>>> originally proposed generic version, as it's possible to use `errors.As` in
>>> a switch statement (eg to test several possible types of error) which isn't
>>> possible with the multi-return `As` variant.
>>>
>>
>> Hmm, that's a good point.
>> However, the main reason I like the two-return-value version more is that
>> you can use it like a normal type-assertion in an if-statement's init
>> section.
>>
>>
>>> A minor variant of the existing API could be:
>>>
>>> ```
>>> func As[E error](err error, asErr *E) bool
>>> ```
>>> which makes the API a little clearer without changing the usage. Sadly
>>> we can't make that change without breaking compatibility.
>>>
>>> Unfortunately, in order to use this proposed version, you still need to
>> pre-declare the variables for each type before the switch/case.
>> I've honestly found it more ergonomic to use a if/else if/ block rather
>> than a switch/case because it lets me contain the scope of these variables
>> anyway.
>>
>> I suppose a simple wrapper that can be used with type-assertions inside a
>> switch/case block would be:
>> ```
>> func AsBool[E error](err error, asErr error) bool {
>> ae, ok := As[E](err)
>> if ok {
>>  asErr = ae
>> }
>> return ok
>> }
>> ```
>> (this would definitely need a better name)
>>
>> Then you'd be able to almost treat your switch/case like a type-switch
>> without needing to pre-declare a variable for every case.
>>
>> ```
>> var asErr error
>> switch {
>>case errors.AsBool[*os.PathError](err, ):
>>fmt.Printf("Path Error! ae: %v", asErr.(*os.PathError))
>>case errors.AsBool[syscall.Errno](err, ):
>>fmt.Printf("ae: %d", asErr.(syscall.Errno))
>> }
>> ```
>>
>> However, I think it would be nicer to use the (originally proposed)
>> two-return errors.As with if/else if.
>>
>> ```
>> if pe, ok := errors.As[*os.PathError](err); ok {
>> fmt.Printf("Path Error: %v", pe)
>> } else if en, ok := errors.As[syscall.Errno](err); ok {
>> fmt.Printf("errno %[1]d: %[1]s", en)
>> }
>> ```
>>
>> Since it looks like the dev.typeparams branch has been merged into
>> master, I was just thinking about how we'd add the two-return-value/generic
>> version of As to the errors package (for go 1.18).
>> Given that the original proposal's code works pretty much as-is, I think
>> the biggest barrier would be a good name. (given that As is already taken)
>>
>>>
>>> On Sun, 19 Sep 2021, 21:15 David Finkel,  wrote:
>>>



 On Sun, Sep 19, 2021 at 4:02 PM David Finkel 
 wrote:

> You might be interested in the original draft proposal for errors.As:
>
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-inspection.md#the-is-and-as-functions
>
> In particular, it originally specified that errors.As would take a
> type-parameter. (the version of generics that was proposed concurrently
> with that proposal was not accepted so they had to go with the current
> (clunkier) interface).
>

 Hmm, actually, the code in that proposal for the generic version of
 errors.As works almost unchanged:
 https://go2goplay.golang.org/p/ddPDlk00Cbl (I just had to change the
 type-parameter syntax)


> On Sun, Sep 19, 2021 at 5:33 AM Haddock  wrote:
>
>>
>> I like the way error handling is done in the xerror package. Things
>> become more concise, but remain very easy to read and understand as in
>> plain Go errorhandling.
>>
>> Here is the example of how to use xerror.As:
>>
>> _, err := os.Open("non-existing")
>> if err != nil {
>> var pathError *os.PathError
>> if xerrors.As(err, ) {
>> fmt.Println("Failed at path:", pathError.Path)
>> }
>> }
>>
>> My idea is to make this even shorter like this:
>>
>> _, err := os.Open("non-existing")
>> myerrors.As(err, os.PathError) {
>>  pathError -> fmt.Println("Failed at path:", pathError.Path)
>> }
>>
>> Think something like that has so far not been suggested. That's why I
>> thought it is justified to drop comment.
>>
>> myerrors.As would also do the check if err is nil. The code in my
>> sample is not valid Go code, I know. It is only pseudo code to show the
>> idea.
>>
>> --
>> You received 

Re: [go-nuts] go/types: differentiate b/w defined named types

['Sebastien Binet' via golang-nuts]

Axel,

On Tue Sep 21, 2021 at 15:56 CET, Axel Wagner wrote:
> The underlying type is defined recursively
> :
>
> Each type T has an underlying type: If T is one of the predeclared
> boolean,
> > numeric, or string types, or a type literal, the corresponding underlying
> > type is T itself. Otherwise, T's underlying type is *the underlying type
> > of the type* to which T refers in its type declaration.
>
>
> (emphasis mine). From a type-system perspective, there is no real
> difference between these two types. The Go type system treats them the
> same.
>
> So, if you need to differentiate between them, you have to go back from
> the
> types-level to the AST level. That's unfortunately a bit difficult,
> AFAIK.
> I think you have to use the `token.Pos` of the `*TypeName` and then
> traverse the `ast.File`s of the package until you find that position.
> That
> should give you an `ast.TypeSpec`, which can tell you if its `Type`
> field
> is an identifier, or a type literal. Not super ergonomic, but AFAIK the
> only way.

ok, thanks for the quick answer.

cheers,
-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/CEFMIPKOYLY5.3L1WQ08C5LPPP%40clrinfopc42.

Re: [go-nuts] go/types: differentiate b/w defined named types

['Axel Wagner' via golang-nuts]

The underlying type is defined recursively
:

Each type T has an underlying type: If T is one of the predeclared boolean,
> numeric, or string types, or a type literal, the corresponding underlying
> type is T itself. Otherwise, T's underlying type is *the underlying type
> of the type* to which T refers in its type declaration.


 (emphasis mine). From a type-system perspective, there is no real
difference between these two types. The Go type system treats them the same.

So, if you need to differentiate between them, you have to go back from the
types-level to the AST level. That's unfortunately a bit difficult, AFAIK.
I think you have to use the `token.Pos` of the `*TypeName` and then
traverse the `ast.File`s of the package until you find that position. That
should give you an `ast.TypeSpec`, which can tell you if its `Type` field
is an identifier, or a type literal. Not super ergonomic, but AFAIK the
only way.

On Tue, Sep 21, 2021 at 3:47 PM 'Sebastien Binet' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> hi there,
>
> I am a bit confused by go/types and defined named types:
>
> https://play.golang.org/p/izESp473jOq
>
> the above link shows a program using the go/types package and shows how
> the four types T0, T1, T2 and T3:
>
> ```
> package p
>
> type T0 struct { F int}
> type T1 struct { T0 }
> type T2 T1
> type T3 T0
> ```
>
> map to types defined in go/types:
>
> T0: type p.T0 struct{F int} -- obj=*types.TypeName typ=*types.Named --
> under=*types.Struct
> T1: type p.T1 struct{p.T0}  -- obj=*types.TypeName typ=*types.Named --
> under=*types.Struct
> T2: type p.T2 struct{p.T0}  -- obj=*types.TypeName typ=*types.Named --
> under=*types.Struct
> T3: type p.T3 struct{F int} -- obj=*types.TypeName typ=*types.Named --
> under=*types.Struct
>
> how would I use go/types to differentiate between T1 and T2?
> they are 2 named types whose underlying types are (eventually):
>  'struct { T0 }'
>
> but, from the doc string of Type.Underlying:
> ```
> // Underlying returns the underlying type of a type
> // w/o following forwarding chains. Only used by
> // client packages (here for backward-compatibility).
> ```
>
> I was actually expecting to get:
> - *types.Struct for t1.Underlying()
> - *types.Named  for t2.Underlying()
>
> so: how could I differentiate between a named type that's defined from
> another named type and one that's defined (directly) from a struct ?
>
>
> --
> 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/CEFLY6WPOVY6.1VEGTAPD57RSO%40clrinfopc42
> .
>

-- 
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/CAEkBMfHU%3DeYODRyy48XM0F1-u4xDd6F-LKVsLcThXkDRcUOADQ%40mail.gmail.com.

[go-nuts] go/types: differentiate b/w defined named types

['Sebastien Binet' via golang-nuts]

hi there,

I am a bit confused by go/types and defined named types:

https://play.golang.org/p/izESp473jOq

the above link shows a program using the go/types package and shows how
the four types T0, T1, T2 and T3:

```
package p

type T0 struct { F int}
type T1 struct { T0 }
type T2 T1
type T3 T0
```

map to types defined in go/types:

T0: type p.T0 struct{F int} -- obj=*types.TypeName typ=*types.Named -- 
under=*types.Struct
T1: type p.T1 struct{p.T0}  -- obj=*types.TypeName typ=*types.Named -- 
under=*types.Struct
T2: type p.T2 struct{p.T0}  -- obj=*types.TypeName typ=*types.Named -- 
under=*types.Struct
T3: type p.T3 struct{F int} -- obj=*types.TypeName typ=*types.Named -- 
under=*types.Struct

how would I use go/types to differentiate between T1 and T2?
they are 2 named types whose underlying types are (eventually):
 'struct { T0 }'

but, from the doc string of Type.Underlying:
```
// Underlying returns the underlying type of a type
// w/o following forwarding chains. Only used by
// client packages (here for backward-compatibility).
```

I was actually expecting to get:
- *types.Struct for t1.Underlying()
- *types.Named  for t2.Underlying()

so: how could I differentiate between a named type that's defined from
another named type and one that's defined (directly) from a struct ?


-- 
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/CEFLY6WPOVY6.1VEGTAPD57RSO%40clrinfopc42.

Re: [go-nuts] What is the total max size of embed content?

[Glen Newton]

Hello,

Looking at https://groups.google.com/g/golang-codereviews/c/xkHLQHidF5s and 
https://github.com/golang/go/issues/9862 and the code to which they refer, 
it seems to me that the limit is 2GB independent of platform (is this 
true?), as the linker is limited to 2e9.
Again, should have done more of my homework!  :-)

https://github.com/golang/go/blob/master/src/cmd/internal/obj/objfile.go#L305

// cutoff is the maximum data section size permitted by the linker 
// (see issue #9862). const cutoff = 2e9 // 2 GB (or so; looks better in 
errors than 2^31)
const cutoff = 2e9 // 2 GB (or so; looks better in errors than 2^31)

The comment indicates that this is a limit in the linker; is this a limit 
in the elf format? If No, could the linker et al be modified to accept 
larger static data?

Thanks,
Glen

On Monday, September 20, 2021 at 8:29:30 PM UTC-4 Glen Newton wrote:

> Hello,
>
> Thanks for this, and also sorry for the lazy question.
>
> My testing on my machine indicates a limit of 2GB total limit on compile: 
>
> too much data in section SXCOFFTOC (over 2e+09 bytes)
> too much data in section SDATA (over 2e+09 bytes)
>
> I have built a bash script that creates large random files of a fixed size 
> and then generates a short Go program that embeds them, increasing the 
> number of files with each run, so you can see when your compile fails. 
> You can find the bash and instructions here: 
> https://github.com/gnewton/test_go_embed
>
> I just threw it together, so might be a little rough around the edges. 
> Feedback welcome.
>
> Question: Wondering why the above error complains about too much data in 
> *two* sections: are the embedded files stored across multiple sections (I 
> know nothing of how this is done internally to the elf format)?
>
> Thanks,
> Glen
>
> On Monday, September 20, 2021 at 5:11:45 PM UTC-4 Ian Lance Taylor wrote:
>
>> On Mon, Sep 20, 2021 at 2:04 PM Glen Newton  wrote: 
>> > 
>> > I am testing this with an increasing number of 1GB files. At 3 files, 
>> and I am getting this error: 
>> > 
>> > compile: writing output: write $WORK/b001/_pkg_.a: no space left on 
>> device 
>> > 
>> > I haven't been able to find how to change $WORK to point to a larger 
>> partition. Suggestions? 
>>
>> Set the TMPDIR environment variable to control temporary files in 
>> general, or the GOTMPDIR environment variable to control just 
>> temporary files created by the go tool. 
>>
>> 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/85284731-937b-4253-a6b5-f345d7f5ccc4n%40googlegroups.com.

Re: [go-nuts] Have you seen any static analysis checker for sync.Mutex.Unlock() call?

[Aram Hăvărneanu]

Congratulations on solving the halting problem!

PS: use defer otherwise you aren't panic-safe.

-- 
Aram Hăvărneanu

-- 
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/CAEAzY38W4miPRdbZZnogYF7KNjEOdAK0KCi4ukbdwhmo%2BZSP6Q%40mail.gmail.com.

[go-nuts] Have you seen any static analysis checker for sync.Mutex.Unlock() call?

[たふみ]

Hi,

I'm seeking the static analysis checker (go vet tool) for missed call 
sync.Mutex.Unlock().

For example: source code is like

type T struct {
  mu sync.Mutex
}

func (t *T) A(a bool) {
  t.mu.Lock()

  if (a) {
// here missing t.mu.Unlock()
return
  }
  t.mu.Unlock()
}

and by running go vet -vettool SOME_AWESOME_CHECKER, I want to find the 
absent of Unlock().

Currently, I'm developing this kind of tool (progress is about 60%), but if 
it exists, I don't want to reinvent the wheel.

So if you have ever seen any other related project, please let me know.

Thanks, 
Tafumi

-- 
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/c6aecbd3-6e40-4556-8d43-86cd3a5f539fn%40googlegroups.com.