Re: [go-nuts] How to pass http.ResponseWriter while writing test case in Go

['Kevin Chowski' via golang-nuts]

Agreed - attempting to obtain 100% test coverage with only small-scale 
tests is not always the best usage of engineering time. Not just writing it 
the first time, but taking into account maintenance as well.

On Monday, April 1, 2019 at 12:07:03 PM UTC-7, Robert Engels wrote:
>
> I wouldn’t test that, test what is producing the response and that it is 
> the correct format. The testing of the encoding if the response is all that 
> is warranted - the other is tested in an integration test. 
>
> On Apr 1, 2019, at 8:07 AM, aniruddh...@nytimes.com  wrote:
>
> Hi, 
>
> I am writing test cases in golang for one of service used in my 
> organisation. In one of file, I have below method --
>
>
> func encodeEdgeResp(_ context.Context, w http.ResponseWriter, response 
> interface{}) error {
> w.Header().Set("Content-Type", "application/json; charset=utf-8")
> return json.NewEncoder(w).Encode(response)
> }
>
>
> I am unable to understand how can I pass/mock http.ResponseWriter over 
> here to run my test cases.
>
> -- 
> 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 golan...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: escape analysis question

['Kevin Chowski' via golang-nuts]

Slightly more minimal, in my testing it seems that the call to 'nothing' is 
not needed.

I do not quite know why, but these two lines seem to show how the compiler 
is reasoning about this escape:

escape.go:4:11:   flow: {heap} = x:
escape.go:4:11: from *y = x (assign) at escape.go:6:5

I do not know why it thinks assigning to '*y' is equivalent to assigning to 
the heap; later it even mentions that `new([]byte) does not escape`, and 
that is the definition of 'y'.

Sorry I'm not more helpful, I looked into this a bit more myself and also 
came up without any good answers.

On Wednesday, March 4, 2020 at 2:58:37 PM UTC-7, burns...@gmail.com wrote:
>
> Hi All,
>
> I am trying to debug why a byte slice is escaping in my program. I have a 
> small reproducible example here:
>
> % cat escape.go
> package main
>
> func main() {
> x := make([]byte, 5)
> y := new([]byte)
> *y = x
> nothing((*y)[3])
> }
>
> func nothing(b byte) {}
> % go tool compile -m -m -l escape.go
> escape.go:4:11: make([]byte, 5) escapes to heap:
> escape.go:4:11:   flow: x = &{storage for make([]byte, 5)}:
> escape.go:4:11: from make([]byte, 5) (spill) at escape.go:4:11
> escape.go:4:11: from x := make([]byte, 5) (assign) at escape.go:4:4
> escape.go:4:11:   flow: {heap} = x:
> escape.go:4:11: from *y = x (assign) at escape.go:6:5
> escape.go:4:11: make([]byte, 5) escapes to heap
> escape.go:5:10: new([]byte) does not escape
>
> It seems to me like neither x nor it's backing array should escape, but 
> I'm having trouble figuring out why it's flagged as escaping from the debug 
> output.
>
> % go version
> go version go1.14 darwin/amd64
>
>
> Any help would be appreciated.
>
> Ethan
>
>

-- 
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/a315ea46-f8ac-4a8f-bc43-c2b16367e72f%40googlegroups.com.

Re: [go-nuts] Deleting map entry from the top level of a nested map doesn't clean the underlying memory

['Kevin Chowski' via golang-nuts]

Guessing based on your latest description: are you aware that there is no 
partial slice collection in GC? That is:


 

> bigSlice := make([]int, 1000*1000)

subSlice := bigSlice[0:1:1]

bigSlice = nil

runtime.GC()

// At this point, bigSlice is still allocated! It cannot be freed by the GC 
> (in the current implementation)

useTheSlice(subSlice) 
>

You have to explicitly reallocate smaller slices (and copy over the data 
from the big slice into each smaller slice) in order for the GC to be able 
to collect each smaller slice individually.
 
As suggested earlier in the thread, if you can create and share a small, 
self-contained program which exhibits the behavior you're speaking of, 
someone on this forum is much more likely to be able to help you. Trying to 
guess how a memory leak is manifesting is just... guesswork without looking 
at full code. There are lots of reasons why memory may not be collected by 
the GC, including random bugs in your program :)


On Tuesday, April 28, 2020 at 2:00:55 PM UTC-6, Naveen Kak wrote:
>
> Basically using the Top command at end of test.
> Let me give a quick summary of the scenario.
>
> Basically we have an application which keeps getting data on a TCP 
> connection, we allocate a global slice to temporarily hold the data and 
> then store in nested maps.
> For every TCP data transaction, we store the data in a  global slice 
> temporarily and then operate on the maps.
> For a certain amount of data, i know what should be the total allocation, 
> but when i check using top command at end of test its almost always double 
> or slightly more.
>
> if I call runtime.GC() on every tcp transaction, memory looks good and end 
> of test it is as expected ( everything reclaimed)
> Is it because the system is heavily loaded ( per sec we may be getting 
> huge no of transactions) so garbage collector cant keep track of 
> the objects to be freed.
> As a test I even tried to block the delete operations on Map, just 
> addition to maps on a smaller scale though, even then memory is almost 
> double of what is expected.
> only solution is calling runtime.GC() on every tcp transaction, then 
> everything is fine.
> I am really not sure whether the map deletions don't work properly or is 
> it just the GC which is not able to work efficiently enough on its own.
>
> Calling GC so often is an overhead and would cause CPU spikes.
>
>
>
>
>
>
>
> On Tue, Apr 28, 2020 at 3:21 AM Ian Lance Taylor  > wrote:
>
>> On Sun, Apr 26, 2020 at 9:57 PM Naveen Kak > > wrote:
>>
>>> I have my system up and running for let's say 10 hours or so where these 
>>> operations on map ( continuous add/delete) keep happening. Memory keeps 
>>> growing and goes very high. 
>>> Eventually at end of test we clear all map entries, memory is reclaimed 
>>> and is good. 
>>> It's basically kind of load test. 
>>> Appreciate your engagement. 
>>>
>>
>> Thanks for the information, but you didn't really answer my question.  
>> How exactly are you measuring whether the memory has been garbage collected?
>>
>> Ian
>>
>>  
>>
>>> On Mon, 27 Apr, 2020, 3:41 AM Ian Lance Taylor, >> > wrote:
>>>
 On Sun, Apr 26, 2020 at 2:48 PM > 
 wrote:

> https://play.golang.org/p/e22ufH-T2M1
>
> This is my sample data structure.
>
> package main
>
> import (
> "fmt"
> )
>
> type MicroChkpt struct {
> comprtype uint32
> MicroChkptInfoMap map[uint32][]byte
> }
>
> type CallChkpt struct {
> FullChkptData []byte
> MicroChkptMap map[uint32]*MicroChkpt
> ckey uint32
> comprtype uint32
> AuditInProgress bool
> }
>
> var CallChkptMap map[uint32]*CallChkpt
>
> func main() {
> fmt.Println("Hello, playground")
> }
>
> So its a nested map structure, 
> CallChkptMap->MicroChkptMap->MicroChkptInfoMap
> So i was expecting on deleting an entry from the top level map 
> CallChkptMap, whole underlying memory used by nested maps would be 
> reclaimed.
>
> Its not happening till all entries are removed from the top level map( 
> then only i see memory dipping), map has ongoing insert and delete 
> operations and grows pretty big.
> Any workarounds to reclaim the memory on deleting the specific entry 
> please?
>
>
> Should i go to the nested maps first, set them to nil and then delete 
> the entry from the top level map?
> Appreciate all your time and inputs.
>


 How exactly are you measuring whether the memory has been garbage 
 collected?

 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/f4b8f164-085c-4d3e-8f51-c16138c3ac83%40googlegroups.com.

[go-nuts] Re: handling constant of maps

['Kevin Chowski' via golang-nuts]

I would do (and have done) what you suggested in your last example, but 
just put the codes into a 'var' block as opposed to a const block, e.g.:

var (
>E270_01 = ErrorCode{"270.01", "this is error description"}

)


I would not personally be concerned about people modifying that public 
value and messing things up because that has never happened within the past 
5 years of my professional career using Go (on two different teams, working 
with a total of up to 30 other people). At least, as far as I know ;)

If you are concerned about future coders misusing these "effectively 
constant" public values, then you should just use a function to return a 
new copy each time instead of having a global/shared version:

func E270_01() ErrorCode {
>return ErrorCode{"270.01", "this is error description"}
> }


In this func example, each time someone needs an ErrorCode to use or 
compare to, they will receive a new copy of ErrorCode, making it impossible 
for misbehaving code to affect other code.

On Monday, May 4, 2020 at 10:30:13 PM UTC-6, Amarjeet Anand wrote:
>
> Hi
>
> I want to declare a constant that maps an *ErrorCode*(string) like 
> "100.01" to its *ErrorDescription*(string) like "Error description of 
> 100.01".
> Declaring Error as *code* and *description* is helpful to monitor logs 
> based based on *ErrorCode* and show the *ErrorDescription* to the client.
>
> Although go cannot create constant of type map, but it can be achieved in 
> multiple ways.
>
> 
> 
> 
> -
> One possible way can be :- 
>
>
> type ErrorCode string
>
> const (
>E270_01 ErrorCode = "270.01"
>E270_02   = "270.02"
> )
>
> var ErrDescription = map[ErrorCode]string{
>E270_01: "this is error description",
>E270_02: "this is error description",
> }
>
> type LogErr struct {
>CodeErrorCode
>Description string
> }
>
> func getLogErr(e ErrorCode) LogErr {
>return LogErr{
>   Code:e,
>   Description: ErrDescription[e],
>}
> }
>
> func TestErrorConstant(t *testing.T) {
>fmt.Println(getLogErr(E270_01))
> }
>
>
>
> This solves our purpose. But the problem is for every new error, we need to 
> change things at two places, (1) Declare const like E270_02 (2) Add an entry 
> in the *ErrDescription* map
>
>
>
> -
>
> Another possible way looks like :- 
>
>
> type ErrorCode string
>
> const (
>E270_01 ErrorCode = "270.01:this is error description"
>E270_02   = "270.02:this is error description"
> )
>
> type LogErr struct {
>Codestring
>Description string
> }
>
> func getLogErr(e ErrorCode) LogErr {
>   * token := strings.Split(string(e), ":")*
>return LogErr{
>   Code:token[0],
>   Description: token[1],
>}
> }
>
> func TestErrorConstant(t *testing.T) {
>fmt.Println(getLogErr(E270_01))
> }
>
>
>
> This way looks promising, but don't really like the way of splitting string 
> using ":"
>
>
>
>
> -
>
> I think best way could have been something like ---
>
> const (
>E270_01 ErrorCode = {"270.01", "this is error description"}
> )
>
>
>
> Since Golang doesn't support the Constant of struct, what could be your 
> approach?
>
> Any suggestion is really appreciated.
>
>

-- 
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/f91631d8-0ce9-49de-8fec-ea3383ad8403%40googlegroups.com.

[go-nuts] Re: How does the Golang compiler handle dependencies?

['Kevin Chowski' via golang-nuts]

C/C++ also has object file caching (depending on how your build is set up, 
I guess). In C/C++ the issue is that you need to possibly open a large 
number of header files when you import any header file.

For example, if I write a file "main.c" which imports "something.h", which 
in turn imports "another.h" and "big.h", and compile just main.c, the 
compiler has to open all three header files and include them in the parsing 
of main.c in order for the compilation to correctly move forward. In Go, 
the compiler arranges things such that it only has to open one file per 
package that is imported. The post you linked goes into greater detail, so 
I will avoid duplicating the details for now, but feel free to ask a more 
specific question and I can try to answer.

There's a bit of nuance there, which the post also goes into: Go's strategy 
ends up requiring that some package much be compiled before any package 
which imports it is compiled. In C/C++ the ordering is a little more 
flexible due to the more decoupled nature of header files, meaning that 
theoretically more builds could occur in parallel. But I suspect that in 
your average Go program the dependency tree would still allow you to 
execute a large number of builds in parallel.

Also note that the article claims this is "the single biggest reason" Go 
compilation is fast, not the only one. There are lots of smaller, yet 
important, reasons as well. For example, parsing the language is pretty 
straightforward because it is not very complex, and linking the final 
binary together is continually being optimized. Plus there are no 
turing-complete meta-language features like the templates C++ compilers 
have to deal with ;)

As for your following, the whole set of files in some package are the 
compilation unit, at least as far as I understand the terms. This is 
because if a.go and b.go are both in the same package (e.g. in the same 
directory), code in a.go can call code in b.go without explicitly declaring 
anything. So before the code in a.go can be fully compiled into an object 
file, b.go must be considered as well.
On Friday, November 13, 2020 at 3:54:34 PM UTC-7 kev kev wrote:

> I recently read the post by Rob Pike about language choices for Golang: 
> https://talks.golang.org/2012/splash.article#TOC_5.
>
> The seventh point refers to how Golang handles dependencies. It mentions 
> an "object file" for packages that a _dependent_ reads.
>
> Below I go through my interpretation of this section:
>
> Example:
>
> package A imports package B.
>
> When I compile package A, package B would have already been compiled. What 
> package A receives is not the AST of package B, but an "Object file". This 
> object file only reveals data about the publicly accessible symbols in that 
> package. From the example, if B had a private struct defined inside of it, 
> this private struct would not be in the object file.
>
> This part seems to make sense for me, hopefully I did not make any 
> mistakes.
>
> It seems that the speedup compared to C/C++ is because the object file is 
> created once per package, while in C/C++ you need to re-compile the thing 
> you are including each time?
>
> Followup question:
>
> Is a single file a compilation unit or is it a package?
>
> Thanks
>
>

-- 
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/04284b0f-7e99-42c8-ae66-2d567e3a4bcan%40googlegroups.com.

[go-nuts] Alignment requirements for 64-bit atomics on 386

['Kevin Chowski' via golang-nuts]

I am debugging an issue 
 in which 
we are seeing a crash on an atomic access; on go 1.14.7 and 1.15.2 this 
reproduces with the following error: 

> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8049f7c]

On gotip (go version devel +3fd4917 Fri Nov 20 20:02:47 2020 + 
linux/amd64) I see the following instead:

> panic: unaligned 64-bit atomic operation

(I'm glad the error message got better! Kudos to whomever did that.)

My confusion is that I don't quite see this restriction being documented in 
sync/atomic's 
docs : ctrl-f for "alignment" only 
reveals information related to MIPS and ARM, whereas this issue is for 
Intel 386. Is this working as intended (e.g. documentation bug) or is this 
something deeper?

-Kevin

-- 
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/6ca9f040-f101-4168-8dc8-ad6d2fcc25d0n%40googlegroups.com.

Re: [go-nuts] Alignment requirements for 64-bit atomics on 386

['Kevin Chowski' via golang-nuts]

Thanks Ian for the very quick reply!

I see you're referencing this:

> On ARM, x86-32, and 32-bit MIPS, it is the caller's responsibility to 
arrange for 64-bit alignment of 64-bit words accessed atomically. The first 
word in a variable or in an allocated struct, array, or slice can be relied 
upon to be 64-bit aligned.

Yeah it's a little unfortunate that it doesn't say i386, I ctrl-f'd for 
"i386" on the page too and I probably would have correctly read that 
sentence if it were in there. Unfortunately I read that sentence multiple 
times but I guess I missed the obvious "x86" in there; my brain saw "ARM 
32  32-bit MIPS" and misread it as "32-bit ARM and 32-bit MIPS". My mistake 
for sure.

Thanks again,
Kevin

On Friday, November 20, 2020 at 1:54:28 PM UTC-7 Ian Lance Taylor wrote:

> On Fri, Nov 20, 2020 at 12:48 PM 'Kevin Chowski' via golang-nuts
>  wrote:
> >
> > I am debugging an issue in which we are seeing a crash on an atomic 
> access; on go 1.14.7 and 1.15.2 this reproduces with the following error:
> >
> > > panic: runtime error: invalid memory address or nil pointer dereference
> > > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8049f7c]
> >
> > On gotip (go version devel +3fd4917 Fri Nov 20 20:02:47 2020 + 
> linux/amd64) I see the following instead:
> >
> > > panic: unaligned 64-bit atomic operation
> >
> > (I'm glad the error message got better! Kudos to whomever did that.)
> >
> > My confusion is that I don't quite see this restriction being documented 
> in sync/atomic's docs: ctrl-f for "alignment" only reveals information 
> related to MIPS and ARM, whereas this issue is for Intel 386. Is this 
> working as intended (e.g. documentation bug) or is this something deeper?
>
> It's down at the very bottom of https://golang.org/pkg/sync/atomic, in
> the "Bugs" section, which for some reason refers to i386 using the
> name x86-32.
>
> 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/b92e1561-441a-4ff3-8d7c-6929801a0b9bn%40googlegroups.com.

Re: [go-nuts] Can we "go get" unreleased standard library packages?

['Kevin Chowski' via golang-nuts]

To follow up on Axel's suggestion to use "tip", this tool will 
automatically download the latest repository and compile it for you, with 
just two simple commands (download/compile the tool with go get, then run 
the tool): https://godoc.org/golang.org/dl/gotip

I used it the other week and I was quite impressed with how smooth it was!

On Wednesday, December 2, 2020 at 6:11:32 PM UTC-7 Uvelichitel wrote:

> $ git checkout master
>
> in source tree provide me `io/fs`
>
>
> On Thu, Dec 3, 2020 at 3:10 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> No, that's not really possible. The stdlib is packaged with the Go 
>> compiler and is very interdependent.
>> It also wouldn't help you a lot, because in go1.15, the `io/fs` package 
>> has no implementation yet. For example, (*os.File).Stat does not return the 
>> correct type, compare
>> https://tip.golang.org/pkg/os/#FileInfo
>> with
>> https://golang.org/pkg/os/#FileInfo
>>
>> If you want to experiment, you have to use a go version compiled from 
>> tip. You can already develop against it, if you use build tags to guard on 
>> go1.16 (though keep in mind that the interfaces could, theoretically, still 
>> change).
>>
>> Otherwise you just have to wait for go1.16. A beta should be released 
>> soon (probably next week, AIUI).
>>
>>
>> On Thu, Dec 3, 2020 at 12:32 AM Matt Mueller  wrote:
>>
>>> Hey there, I'd like to try the io/fs package on Go 1.15. Is there an 
>>> easy way to do this?
>>>
>>> I tried without much expectation:
>>>
>>> go get -u github.com/golang/go/src/io/fs
>>>
>>> But was greeted with this error:
>>>
>>> go: found github.com/golang/go/src/io/fs in github.com/golang/go/src 
>>> v0.0.0-20201202201757-2d0258d49568
>>> go get: github.com/golang/go/s...@v0.0.0-20201202201757-2d0258d49568 
>>> : 
>>> parsing go.mod:
>>> module declares its path as: std
>>> but was required as: github.com/golang/go/src
>>>
>>> Any ideas? Thanks!
>>>
>>> -- 
>>> 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/8857da92-774a-453b-9c81-46bf818b38b6n%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEMHcb5zNiPdH-WAfC5-QVkxpwzDh8oeULE77TN103SjQ%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/4f1cdbc6-b9ba-4379-a21f-8b2c46b0bf67n%40googlegroups.com.

[go-nuts] Re: embed.FS and memory limitations

['Kevin Chowski' via golang-nuts]

If you had a simple test program or microbenchmark which put some numbers 
behind your concerns, I think you'll get a bit more traction. Have you 
tried to measure the effect of page faults on reading data from embedded 
files (or, I guess, any sort of data that has fallen out of the pagecache)? 
I'm interested in calibrating my gut, which is currently surprised that 
you're talking about page fault latency in the context of a 
garbage-collected language like Go, but I'm happy to be proven wrong :)

(And from a tuning side, if you're only concerned about tying up Ps I 
suspect you could increase GONUMPROCS to get threads "running", but of 
course that might cause trouble if you have something that is CPU-bounded 
in the server.)

On Tuesday, February 16, 2021 at 9:48:30 AM UTC-7 ca...@mercari.com wrote:

> Was going through the implementation of embed.FS and started wondering 
> about the lack of WriteTo - specifically about the implications in case 
> the embedded data is not present in memory e.g. because it got evicted due 
> to memory pressure - or simply due to outright not fitting in memory. Won’t 
> this tie Ps up while the data is faulted in, with no way for the scheduler 
> to park the offending Gs?
> The design doc discusses some arguments against adding WriteTo 
> 
>  
> but does not discuss the issue described above. Am I missing something?
> Obviously, WriteTo wouldn't solve this problem above for *all* cases 
> (e.g. all cases in which the WriteTo implementation is unable to bypass 
> the userspace copy) although it should help significantly when it does 
> (e.g. in case of embedded static files to be served over plain HTTP). Or 
> maybe reads from embed.FS instances could try to opportunistically 
> madvise(MADV_WILLNEED) and yield if mincore returns that the pages are 
> not (yet) resident in memory? Or the scheduler/sysmon should be taught how 
> to handle that case (e.g. with userfaultfd on Linux)?
>
> Carlo
>
>

-- 
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/b49a03e3-ead3-4c11-9044-85affe8e1017n%40googlegroups.com.

[go-nuts] Re: %v for []string{} and []string{""}

['Kevin Chowski' via golang-nuts]

The "%#v" print verb is intended to be used for unambiguous printing of a 
type, but that means it will have a prefix of `[]string` in order to ensure 
the type is unambiguous. I personally use %q a lot any time I know I have a 
string (or set of strings) which might be ambiguous in some way, but I 
don't want the `[]string` prefix in there. 
See: https://play.golang.org/p/70Ryd50IGt6

On Thursday, March 18, 2021 at 4:31:32 AM UTC-6 Brian Candler wrote:

> Sure.  I don't have a problem with nil slice and empty slice showing the 
> same, because in all important ways they behave the same - i.e. they have 
> len() of 0, you can append() to them, etc.  The only behavioural difference 
> I can think of is if you explicitly test "foo == nil".
>
> However, a slice with len=1 that showed the same as one with len=0, was 
> what confused me :-)
>
> On reflection, %v is intentionally ambiguous.  There are other examples, 
> e.g.
> - []string{"a","b"} and []string{"a b"}
> - []string{"", ""} and []string{" "}
>
> On Wednesday, 17 March 2021 at 21:24:46 UTC tapi...@gmail.com wrote:
>
>> Printing a nil slice also get the same output [].
>>
>> I remembered Rob Pike ever said in an issue thread that this can't be 
>> changed now for compatibility reason.
>>
>> On Monday, March 15, 2021 at 8:18:46 AM UTC-4 Brian Candler wrote:
>>
>>> I was slightly surprised to discover that the Print() output for an 
>>> empty slice, and a 1-element slice containing the empty string, are the 
>>> same:
>>>
>>> https://play.golang.org/p/btkzgk4LMT9
>>>
>>> It does follow logically from the rules 
>>> .  I guess I need to train 
>>> myself to use %q or %#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/9e87e9bc-fbd9-4729-8721-689a62db8130n%40googlegroups.com.

[go-nuts] Re: Trouble exporting function with anonymous struct containing anonymous fields as parameter

['Kevin Chowski' via golang-nuts]

It's not clear to me what problem you are solving. Can you clarify *why* 
you want to do this?

For what it's worth, this seems correct to me: a function defined in 
package X should not be able to access the unexported fields of a struct in 
package Y. If you embed a 'byte' into a struct, that is an exported field 
and should not be accessible to other packages.

On Tuesday, November 16, 2021 at 3:51:39 PM UTC-7 oxc...@gmail.com wrote:

> Hello, my issue is similar to: 
>
> https://stackoverflow.com/questions/38784963/exporting-functions-with-anonymous-struct-as-a-parameter-cannot-use-value-type
>
> In this particular case, it is fixed by exporting the fields capitalizing 
> the field name. But, what if the struct fields are also anonymous?
>
> main.go:
> 
> package main
>
> import "a/b"
>
> func f(s struct{ byte }) {}
>
> func main() {
> s := struct{ byte }{}
> f(s)   // This works
> b.F(s) // This gives an argument type error
> }
> 
>
> b/b.go:
> 
> package b
>
> func F(c struct{ byte }) {
> }
> 
>
> By building this code, we get the following compiler error:
> `cannot use s (type struct { byte }) as type struct { byte } in argument 
> to b.F`
>
> In my opinion, it should be allowed to export the unnamed (anonymous) 
> types so the struct can be used anywhere else. Opinions on this?
>

-- 
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/ad8f56b7-92ec--aa1b-97cd1d08dbf1n%40googlegroups.com.

[go-nuts] Re: Trouble exporting function with anonymous struct containing anonymous fields as parameter

['Kevin Chowski' via golang-nuts]

Sorry, I included a typo. I have edited my reply below to fix it.

On Tuesday, November 16, 2021 at 8:25:47 PM UTC-7 Kevin Chowski wrote:

> It's not clear to me what problem you are solving. Can you clarify *why* 
> you want to do this?
>
> For what it's worth, this seems correct to me: a function defined in 
> package X should not be able to access the unexported fields of a struct in 
> package Y. If you embed a 'byte' into a struct, that is an *un*exported 
> field and should not be accessible to other packages.
>

 

>
> On Tuesday, November 16, 2021 at 3:51:39 PM UTC-7 oxc...@gmail.com wrote:
>
>> Hello, my issue is similar to: 
>>
>> https://stackoverflow.com/questions/38784963/exporting-functions-with-anonymous-struct-as-a-parameter-cannot-use-value-type
>>
>> In this particular case, it is fixed by exporting the fields capitalizing 
>> the field name. But, what if the struct fields are also anonymous?
>>
>> main.go:
>> 
>> package main
>>
>> import "a/b"
>>
>> func f(s struct{ byte }) {}
>>
>> func main() {
>> s := struct{ byte }{}
>> f(s)   // This works
>> b.F(s) // This gives an argument type error
>> }
>> 
>>
>> b/b.go:
>> 
>> package b
>>
>> func F(c struct{ byte }) {
>> }
>> 
>>
>> By building this code, we get the following compiler error:
>> `cannot use s (type struct { byte }) as type struct { byte } in argument 
>> to b.F`
>>
>> In my opinion, it should be allowed to export the unnamed (anonymous) 
>> types so the struct can be used anywhere else. Opinions on this?
>>
>

-- 
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/8c3f00b5-aa62-417f-becc-3ab5dce6e466n%40googlegroups.com.

[go-nuts] Re: Goroutines - handles, signals, and signal handlers

['Kevin Chowski' via golang-nuts]

In Go, goroutines are meant to explicitly signal each other; further, it 
seems very intentional that goroutines are never interrupted in the middle 
of execution like an interrupt service routine might in a lower-level 
situation.

It was mentioned in a prior message a bit, but to add more details: I think 
I would solve this problem using channels and a select statement rather 
than busy waiting (e.g. looping on TryLock). Specifically, if you use a 
buffered channel of capacity 1 as a mutual exclusion guarantee (send to 
channel "locks" it, receive "unlocks" it), then you can use another channel 
as the "interrupt delivery" mechanism. Using a select statement allows you 
to simultaneously attempt locking and interrupt triaging. Of course this 
requires your goroutines to explicitly check for interrupts from time to 
time, but as I mentioned, I expect this is an intentional design choice of 
the Go programming language and I doubt things will change.

Note that this passing around of a channel (in the form of a 
context.Context: https://pkg.go.dev/context) is the "right" way to listen 
for timeout signals in Go too. Timeouts are sometimes implemented as some 
sort of interrupt in other languages, but the preference for Go is to 
explicitly check for that signal. This drastically simplifies the 
programming experience because avoids the need to reason about your 
goroutine arbitrarily executing different code in the middle of some other 
statement.

On Thursday, March 17, 2022 at 3:14:51 PM UTC-6 mumbling...@gmail.com wrote:

> Thanks! It's nice to have it natively I suppose. Still doesn't completely 
> solve my issue, but at least I won't have to implement custom lock 
> primitives.
>
> On Thursday, March 17, 2022 at 1:47:47 PM UTC+1 peterGo wrote:
>
>> Go1.18 has a new Mutex TryLock method.   
>> https://pkg.go.dev/sy...@go1.18#Mutex.TryLock 
>> 
>>
>> Petr
>>
>> On Wednesday, March 16, 2022 at 9:36:50 PM UTC-4 mumbling...@gmail.com 
>> wrote:
>>
>>> I'm currently working on a project where I emulate a RISC-V processor 
>>> for the purpose of using Go when teaching concepts of operating systems.
>>> I'd like for the emulator to resemble a "real" processor to the point 
>>> that a realistic operating system can be implemented with most of the 
>>> interesting challenges that this encompasses.
>>> One of these challenges is the management of translation caches across 
>>> multiple cores which may sometimes require TLB shootdowns.
>>>
>>> A quick summary of TLB shootdowns: process P has two threads T1 and T2 
>>> that run on cores A and B respectively.
>>> When T1 makes a request to deallocate a page, core A has to ensure that 
>>> T2 on core B invalidates some cached translations before it marks the page 
>>> as free, lest B (executing T2) might find the translation in cache and 
>>> write to a page that T2 no longer should have access to.
>>>
>>> My current approach to this is that instead of using a `sync.Mutex` and 
>>> `Lock()`, I have created a custom `UntilLock(f func())` which takes in 
>>> a function that should be repeatedly executed until the lock is acquired.
>>>
>>> Current implementation: https://pastecord.com/hofoloxuru.go
>>>
>>> Notice that every mutex where a `Lock`-`Unlock`-pair might wrap an 
>>> interrupt, has to use the `UntilLock` as a `Lock` might cause the 
>>> goroutine to block and never check interrupts.
>>> The issue is further complicated if one resource R might be locked in 
>>> function F and another resource S is locked in function G.
>>> In this case, goroutine A might enter F, successfully acquire R, then 
>>> signal goroutine B.
>>> At the same time, B enters G, successfully acquires S, then signals 
>>> goroutine A.
>>> We have a deadlock.
>>> This is pretty easily resolved though as we just add the interrupt check 
>>> to the loop where F and G wait for the other goroutine to execute their 
>>> handlers.
>>>
>>> An idea came to me though...
>>> Life would be much easier if Go had signalling between goroutines.
>>> One could extend the syntax as `h := go f() handler` where `handler`
>>> would have the signature: `func handler(signal int)`
>>> You would then signal it with something like `s := sig h 1` to send a 
>>> signal of 1 to the goroutine associated with h.
>>>
>>> Idea for how code would look with signalling: 
>>> https://pastecord.com/qunyqejexo.go
>>>
>>> This would completely eliminate the issue I am currently facing and 
>>> though I'm no expert in the field, I believe Go's scheduler could make the 
>>> implementation require very little effort and the overhead would be 
>>> practically non-existent.
>>> This signalling would look a lot like OS signals and is a powerful 
>>> feature that isn't too complex in my opinion.
>>>
>>

-- 
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

[go-nuts] Better replacement for strings.Title?

['Kevin Chowski' via golang-nuts]

strings.Title is newly deprecated 
,
 
but unfortunately the suggested replacement (golang.org/x/text/cases) 
doesn't seem to be equivalent for my usecase. At least, I can't figure out 
how to make it equivalent :)

Specifically, I wrote some code that relies on converting a string like 
"myInput" into "MyInput", which is what strings.Title does. Unfortunately, 
the cases package seems to turn it into "Myinput": 
https://go.dev/play/p/yucD99ytNK7 . I've tried a few different language.Tag 
values but nothing seems to work the way I need it to work.

Will I have to just keep using this old version, or is there a way to get 
the new library working the way I need it to work?

Thanks again in advance for the advice,
Kevin

-- 
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/fd29246b-b684-4f52-b540-7730d9f81a70n%40googlegroups.com.

[go-nuts] Re: Better replacement for strings.Title?

['Kevin Chowski' via golang-nuts]

I guess "Better" is not really what I mean... maybe more accurately I need 
something "closer" to strings.Title.

On Wednesday, March 30, 2022 at 9:59:24 AM UTC-6 Kevin Chowski wrote:

> strings.Title is newly deprecated 
> ,
>  
> but unfortunately the suggested replacement (golang.org/x/text/cases) 
> doesn't seem to be equivalent for my usecase. At least, I can't figure out 
> how to make it equivalent :)
>
> Specifically, I wrote some code that relies on converting a string like 
> "myInput" into "MyInput", which is what strings.Title does. Unfortunately, 
> the cases package seems to turn it into "Myinput": 
> https://go.dev/play/p/yucD99ytNK7 . I've tried a few different 
> language.Tag values but nothing seems to work the way I need it to work.
>
> Will I have to just keep using this old version, or is there a way to get 
> the new library working the way I need it to work?
>
> Thanks again in advance for the advice,
> Kevin
>

-- 
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/d6d20c39-1b62-4207-bb72-235b90721eb8n%40googlegroups.com.

[go-nuts] Re: Better replacement for strings.Title?

['Kevin Chowski' via golang-nuts]

Someone replied off-list and suggested using the cases.NoLower option while 
initializing the Caser. And it worked! Thanks!

On Wednesday, March 30, 2022 at 10:15:40 AM UTC-6 Kevin Chowski wrote:

> I guess "Better" is not really what I mean... maybe more accurately I need 
> something "closer" to strings.Title.
>
> On Wednesday, March 30, 2022 at 9:59:24 AM UTC-6 Kevin Chowski wrote:
>
>> strings.Title is newly deprecated 
>> ,
>>  
>> but unfortunately the suggested replacement (golang.org/x/text/cases) 
>> doesn't seem to be equivalent for my usecase. At least, I can't figure out 
>> how to make it equivalent :)
>>
>> Specifically, I wrote some code that relies on converting a string like 
>> "myInput" into "MyInput", which is what strings.Title does. Unfortunately, 
>> the cases package seems to turn it into "Myinput": 
>> https://go.dev/play/p/yucD99ytNK7 . I've tried a few different 
>> language.Tag values but nothing seems to work the way I need it to work.
>>
>> Will I have to just keep using this old version, or is there a way to get 
>> the new library working the way I need it to work?
>>
>> Thanks again in advance for the advice,
>> Kevin
>>
>

-- 
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/3ba30f22-9a16-4d80-b977-e0abe6ca3362n%40googlegroups.com.

[go-nuts] Re: Error-checking with errors.As() is brittle with regards to plain vs pointer types

['Kevin Chowski' via golang-nuts]

If some func advertises the type of error it returns, it should mention the 
precise type. That is, if a function returns *ABC in error conditions, it 
should document that it returns *ABC (not ABC, that is a different type).

Why is that no sufficient? An API already must document the type of error 
they are returning, otherwise you shouldn't be depending on those internal 
implementation details anyway, so I see the problem of checking for "*ABC" 
vs "ABC" no different than the problem of checking for "SomeError" and 
"AnotherRandomErrorType": you must rely on the documentation to be correct 
in all cases.

On Wednesday, September 21, 2022 at 1:26:31 PM UTC-6 cpu...@gmail.com wrote:

> Consider https://go.dev/play/p/jgPMwLRRsqe:
>
> errors.As(err, ) will not match if error is of pointer type. 
> As a result, a library consumer needs to understand if a library returns 
> Error or *Error. However, that is not part of the API spec as both returns 
> would satisfy error if Error() is implemented on the plain type.
>
> A potential workaround would be using Error.As(any) to match plain/pointer 
> type as part of the library. However, it seems counterintuitive having to 
> do so if errors.As() doesn't by default.
>
> Would it make sense (and I would like to propose) to expand errors.As() to 
> match plain receiver types even when err is a pointer to the same 
> underlying plain type.
>
> What do you think?
>
> Cheers,
> Andi
>

-- 
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/d4a346d2-5ccd-4bc5-a3b9-0772e9be39f7n%40googlegroups.com.

[go-nuts] WebAssembly and Filesystem access

['Kevin Chowski' via golang-nuts]

Hey all,

I couldn't find a prior thread or other information on the web after a bit 
of searching, but if this is answered elsewhere I'd appreciate a link to 
follow.

I am on a project which primarily ships a Go command line interface (CLI), 
but we have aspirations of using the wasm compilation mode to also 
distribute a simple webapp version of it, while sharing most of the code.

Currently simple things work perfectly. (To everyone involved with this: 
great work!) The next big hurdle is the fact that we cache things on disk 
for later reuse, so  things are failing out-of-the-box any time we attempt 
to touch the filesystem. Luckily, in our case, the fact that we are 
touching the filesystem is a bit incidental (its used as a cache for making 
consecutive CLI invocations faster), and as long as the system was 
consistent for the lifetime of the main Go process things will work just 
fine.

We /could/ pass a filesystem object across the codebase, and maybe we will 
one day we will anyway for some other reasons, but I'd rather not have to 
do that just to get further with this webapp prototype: it's a lot of 
tedious plumbing, and there is a nontrivial amount of code to touch.

So instead I decided to try some global-mutable-at-startup variables for 
things like os.OpenFile, os.Remove, etc, that should be easy to cleanup if 
we decide not to move forward with the prototype; but even then, there are 
plenty of random things I have to do to get this to work. I've spent about 
2 hours on this direction so far and I keep hitting unexpected roadblocks - 
thus this email seeking out a new strategy.

Are there any plans to automatically support filesystems on wasm-compiled 
Go applications? Even an ephemeral, in-memory filesystem would basically 
solve all of my problems without having to change any code on my end, which 
would be nice.

In lieu of that, does anyone have any tips about how I could go about doing 
this in a better way?

-Kevin

-- 
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/557c3a1b-9a21-4721-8e4d-c5225b8043b2n%40googlegroups.com.

Re: [go-nuts] WebAssembly and Filesystem access

['Kevin Chowski' via golang-nuts]

I recently learned that WASI 
(https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md) 
supports filesystem abstractions directly for WASM code.

Is there an plan to integrate this into Go?

On Saturday, November 5, 2022 at 5:59:08 AM UTC-6 Konstantin Khomoutov 
wrote:

> On Fri, Nov 04, 2022 at 02:08:08PM -0700, 'Kevin Chowski' via golang-nuts 
> wrote:
>
> [...]
> > I am on a project which primarily ships a Go command line interface 
> (CLI), 
> > but we have aspirations of using the wasm compilation mode to also 
> > distribute a simple webapp version of it, while sharing most of the code.
> [...]
> > The next big hurdle is the fact that we cache things on disk 
> > for later reuse, so things are failing out-of-the-box any time we 
> attempt 
> > to touch the filesystem. Luckily, in our case, the fact that we are 
> > touching the filesystem is a bit incidental (its used as a cache for 
> making 
> > consecutive CLI invocations faster), and as long as the system was 
> > consistent for the lifetime of the main Go process things will work just 
> > fine.
> > 
> > We /could/ pass a filesystem object across the codebase, and maybe we 
> will 
> > one day we will anyway for some other reasons, but I'd rather not have 
> to 
> > do that just to get further with this webapp prototype: it's a lot of 
> > tedious plumbing, and there is a nontrivial amount of code to touch.
> > 
> > So instead I decided to try some global-mutable-at-startup variables for 
> > things like os.OpenFile, os.Remove, etc, that should be easy to cleanup 
> if 
> > we decide not to move forward with the prototype; but even then, there 
> are 
> > plenty of random things I have to do to get this to work. I've spent 
> about 
> > 2 hours on this direction so far and I keep hitting unexpected 
> roadblocks - 
> > thus this email seeking out a new strategy.
> > 
> > Are there any plans to automatically support filesystems on 
> wasm-compiled 
> > Go applications? Even an ephemeral, in-memory filesystem would basically 
> > solve all of my problems without having to change any code on my end, 
> which 
> > would be nice.
>
> I'm not a Go developer, but I'd say it is unlikely due to the combination 
> of
> these two facts:
>
> - The os package was implemented as a sort-of grab bag of many features
> one expects on a typical OS (hence the name). The fact the filesystem
> operations were implemented in that package directly and not elsewhere
> is the direct manifestation of that approach.
> An environment in which WASM runs in a browser is too different from that
> provided by a typical OS, so I cannot see how one could sensibly implement
> in GOOS=js.
>
> - Even if some sort of FS emulation were to be implemented for GOOS=js,
> the question is: which one exactly? Keeping stuff in memory in just one
> way of doing things. While I'm not a web developer, I know of at least
> session storage and local storage which provide for two levels of
> persistence beyond keeping stuff in memory. Which one to pick for
> implementing stuff from the os package?
>
> > In lieu of that, does anyone have any tips about how I could go about 
> doing 
> > this in a better way?
>
> If you need a hard-and-fast solution, I'd propose you're trying to abstract
> your stuff away on a wrong level. I think it would be cleaner to factor out
> your persistence code into a set of functions "store this stuff" and "load
> that stuff"; the default implementations would call out to the os package, 
> and
> the wasm implementation would use either approach you select: keeping 
> things
> in memory, using local storage etc.
>
> I mean, trying to implement and pass around through the whole codebase
> something like a "filesystem accessor" switchable at runtime is only worth 
> it
> if your code makes heavy use of the filesystem in nontrivial way. I'd say 
> that
> it's better to abstract away high-level store/load operations.
>
>

-- 
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/dd8306ab-75bf-4bb6-a9ac-3c9f778665a7n%40googlegroups.com.

Re: [go-nuts] Is it possible to "extract" the generic [T] from a reflected type ?

['Kevin Chowski' via golang-nuts]

If I understand correctly, the restriction is that the compiler has to know 
all possible instantiations of a generic func/type/etc at compile time. So 
listing out each specific Hello instantiation is the workaround, which 
allows you to approximate this if you have a closed set of types you want 
to use. Assuming your Hello function truly doesn't need inputs or outputs 
it's actually pretty simple, for a closed set of types: 
https://go.dev/play/p/JAw4tXOLwYT. If you need inputs/outputs of type T 
then you have to do more hoop jumping, or just invoke the function through 
reflect.

Depending on what the rest of the code looks like, you could convince the 
compiler to do what you want if you are just passing functions statically 
and making Do a generic function too. Again, it's all about just making 
sure the compiler can transitively find all of the real instantiated types 
when things are eventually used. If you share more code maybe my example 
can be better, but here's the sort of thing I 
mean: https://go.dev/play/p/AanjJKg8Hf_i

But obviously this workaround won't work if you really need things to be 
dynamic.
On Tuesday, April 9, 2024 at 10:51:06 AM UTC-6 Ian Lance Taylor wrote:

> On Tue, Apr 9, 2024 at 9:41 AM Mihai Barbu  wrote:
> >
> > I need to call some generic functions with types that are now known at 
> compile time. Is it possible to do this?
> > See the code below (vastly reduced).
> >
> > // fv is a function that returns an unknown type
> > func Do(fv reflect.Value){
> > // get the first returned type by function fv
> > vt := fv.Type().Out(0)
> > // how to call `Hello` with `v` ?
> > // Obviously the code below is incorrect
> > Hello[vt]()
> > }
> >
> > func Hello[T any](){
> > // do something with T
> > json.Marshal(new(T))
> > }
>
> This is not possible. Sorry.
>
> 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/4a3051a0-cba3-4f91-92a1-4954b315ff75n%40googlegroups.com.

Re: [go-nuts] generics question

['Kevin Chowski' via golang-nuts]

If you are just unhappy about the A and A* while using a literal for C: 
note that if you are willing/able to write a wrapper function instead of 
using a literal, type inference works well today:

func NewC[E any, P Settable[E]](val []E) C[E, P] {
return C[E, P]{Val: val}
}
var c = NewC([]A{1, 2, 3})

Full: https://go.dev/play/p/JIk1L4rBXEs

On Tuesday, April 23, 2024 at 11:35:03 AM UTC-6 Ian Lance Taylor wrote:

> On Mon, Apr 22, 2024 at 11:01 PM Jochen Voss  wrote:
> >
> > This works, see my code below. Followup question: is there a way to 
> refer to the new type without having to list both the element type and the 
> pointer type separately?
>
> Unfortunately there is not. At some point in the future the language
> may support type inference for type arguments to types, for cases
> where one type argument can be inferred from another type argument.
> Currently that is not supported because there are some complex issues
> involving cyclical types that need to be resolved or side-stepped.
>
> In Go 1.23 I think it should be possible to simplify using these kinds
> of types with a type alias as in "type X[E] = C[E, *E]".
>
> 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/3d18ca3a-eae4-4ea7-9a9b-c6d347c38683n%40googlegroups.com.

Re: [go-nuts] generics question

['Kevin Chowski' via golang-nuts]

Sorry for the noise - looks like you meant when passing around objects by 
this type, not just creating objects.

On Friday, May 3, 2024 at 11:02:37 AM UTC-6 Kevin Chowski wrote:

> If you are just unhappy about the A and A* while using a literal for C: 
> note that if you are willing/able to write a wrapper function instead of 
> using a literal, type inference works well today:
>
> func NewC[E any, P Settable[E]](val []E) C[E, P] {
> return C[E, P]{Val: val}
> }
> var c = NewC([]A{1, 2, 3})
>
> Full: https://go.dev/play/p/JIk1L4rBXEs
>
> On Tuesday, April 23, 2024 at 11:35:03 AM UTC-6 Ian Lance Taylor wrote:
>
>> On Mon, Apr 22, 2024 at 11:01 PM Jochen Voss  wrote: 
>> > 
>> > This works, see my code below. Followup question: is there a way to 
>> refer to the new type without having to list both the element type and the 
>> pointer type separately? 
>>
>> Unfortunately there is not. At some point in the future the language 
>> may support type inference for type arguments to types, for cases 
>> where one type argument can be inferred from another type argument. 
>> Currently that is not supported because there are some complex issues 
>> involving cyclical types that need to be resolved or side-stepped. 
>>
>> In Go 1.23 I think it should be possible to simplify using these kinds 
>> of types with a type alias as in "type X[E] = C[E, *E]". 
>>
>> 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/0791f433-23f2-45d9-961a-28c90bed6d77n%40googlegroups.com.

Re: [go-nuts] Re: raw bit types without arithmetic

['Kevin Chowski' via golang-nuts]

By the way - I definitely don't feel strongly about this, and I am just 
guessing that it's more likely to support new operators for existing types 
than it is to create new built-in types. I think bitsN types are fine, 
although again I don't know if I'd personally ever use them. But I am 
enjoying the conversation so far, so here are some more thoughts I had :)

I think the fact that you can compare huge byte arrays with == means that 
there is some desire inside the Go compiler team to support variable-length 
operations based on the type regardless of whether it can be "efficiently" 
compiled on all systems, so I don't see that aspect as being inconsistent 
with the existing language. As another example that is more dynamic (and 
therefore even more "surprising"), doing `string1 == string2` might take a 
very long time if string1 and string2 have the same contents and have a 
huge length. To me, those seem the same (or worse) as accepting that 
`byteArray1 | byteArray2` might take a long time if they are statically 
known to be long byte arrays; it seems pretty straightforward that doing an 
operation on `[N]byte` will be faster than an operation on `[N*1000]byte` 
and I think people will intuit that.

As for whether it would be weird to support some operations on some arrays 
but not others, technically this is already true: you can't use == on an 
array when the elements are not comparable. And people seem OK with that 
:)   there are also some other special cases for the byte type, e.g. you 
can convert a byte slice into a string (and viceversa) but not with an int 
slice. I personally don't see this inconsistency as an issue or learning 
impediment, but I can understand that someone may disagree with my 
perspective here.

(Another idea: how about both? e.g. if we had both `bitsN` types AND the 
ability to use bitwise operations on arrays of (only) bitsN types? Or 
something along those lines. That would open up the ability to express some 
SIMD operations in otherwise extremely idiomatic-looking code, while also 
supporting the smaller-scale operations you are suggesting.)

On Tuesday, May 14, 2024 at 12:27:01 PM UTC-6 jimmy frasche wrote:

> Arrays are arrays regardless of what they're arrays of. So it would be
> strange for arrays of certain things to have properties that other
> arrays don't have and bitwise ops don't make sense for arrays of, say,
> strings.
>
> Also some processors support these sizes natively but wouldn't support
> a [4096]byte natively. On processors that don't support all or some of
> these sizes it would need to fake it by doing m operations† but that's
> bounded and if, for example, the target processor supports 256 bit but
> not 512 bit values it can use two 256 ORs instead of four 64 bit ORs.
> Maybe that could be made to work in general and if so that would be
> great but it's not the only benefit of these types.
>
> † except for shifts, those would have to deal with carries. That may
> be a problem, but I think even then it should be fast enough to not be
> an issue the way faking div or something very expensive like that
> would be.
>
> On Mon, May 13, 2024 at 8:41 PM Kevin Chowski  wrote:
> >
> > Sorry, sent too early.
> >
> > Obviously that doesn't support the bitwise type conversion you 
> mentioned; I don't really have an opinion on that one, I don't really 
> convert from float to bits very often.
> >
> > It seems like the compiler optimizations you mention could happen with 
> or without these extra types, if such optimizations just worked on byte 
> arrays in general.
> >
> > On Monday, May 13, 2024 at 9:38:36 PM UTC-6 Kevin Chowski wrote:
> >>
> >> How about just allowing bitwise operations on byte arrays (of the same 
> length)?
> >>
> >> On Monday, May 13, 2024 at 2:51:19 PM UTC-6 jimmy frasche wrote:
> >>>
> >>> I'm not 100% sure if this is a good idea but it's been knocking around
> >>> in my head all week so I thought I'd share in case it has any merit:
> >>>
> >>> Introduce bitsN types for N=8, 16, 32, 64, 128, 256, and 512.
> >>>
> >>> These are similar to uintN but they are unordered and have no
> >>> arithmetic operations defined.
> >>>
> >>> They only have literals, comparison, and bitwise operations.
> >>> (fmt.Print and friends should render them in hex by default.)
> >>>
> >>> Conversions between the numeric types and the bitN are allowed, which,
> >>> for example, let's us rewrite math.Float64bits as simply
> >>>
> >>> func Float64bits(f float64) uint64 {
> >>> return uint64(bits64(f))
> >>> }
> >>>
> >>> Since there are no arithmetic operations, the 128+ sizes should be
> >>> fairly efficient to fake on architectures without special
> >>> instructions/registers.
> >>>
> >>> Potential uses:
> >>>
> >>> UUIDs could be stored as a bits128 instead of a [2]uint64 or [16]byte.
> >>>
> >>> SIMD vectors could be created and stored easily, even if they need
> >>> assembly to operate on them efficiently.
> >>>
> >>> Same for int128/uint128 values or eve