[go-nuts] Deep printing in the reflect package

[aind...@gmail.com]

Often on my team, Go programmers (particularly new ones) simply want full 
visibility into a data structure when debugging. For those who aren't 
familiar with pointers, seeing a hexadecimal number show up in a log can be 
really frustrating. I usually point them 
to https://github.com/davecgh/go-spew 
or https://github.com/sanity-io/litter. Although they can be heavy-handed 
with their unsafe package dependency and fancy formatting, they are 
indispensable when debugging data structures like syntax trees.

I wonder it's worthwhile to add this functionality to the reflect package, 
and take advantage of the functionality that DeepEquals uses. I'm not a fan 
of Dump functions that just take an io.Writer. Why not add a named type for 
interface{} or reflect.Value called reflect.Deep, which implements 
fmt.Formatter? Then, packages that use fmt will have more precise control 
over formatting, and we can maybe add special formatting directives for 
reflect.Deep.

What do you think?

-- 
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/6f1c9bea-c2b6-4a7c-a37e-ef3abb8a3dd2n%40googlegroups.com.

Re: [go-nuts] Deep printing in the reflect package

[aind...@gmail.com]

I agree that this functionality can be implemented outside the standard 
library. However, traversing nested data structures does seem to fall into 
reflect's domain. In particular, one would have to deal with unexported 
fields and pointer cycles.

I can also see how a newcomer would think the standard library would be 
able to print any value in the language.

> there will inevitably be a lot of desire for customization of the printed 
output, which will lead to a complex API.

This is a fair. Maybe the goal should be to provide a general mechanism to 
walk data structures, rather than format them?

Akhil
On Friday, September 4, 2020 at 4:24:23 PM UTC-4 Ian Lance Taylor wrote:

> On Fri, Sep 4, 2020 at 1:11 PM aind...@gmail.com  
> wrote:
> >
> > Often on my team, Go programmers (particularly new ones) simply want 
> full visibility into a data structure when debugging. For those who aren't 
> familiar with pointers, seeing a hexadecimal number show up in a log can be 
> really frustrating. I usually point them to 
> https://github.com/davecgh/go-spew or https://github.com/sanity-io/litter. 
> Although they can be heavy-handed with their unsafe package dependency and 
> fancy formatting, they are indispensable when debugging data structures 
> like syntax trees.
> >
> > I wonder it's worthwhile to add this functionality to the reflect 
> package, and take advantage of the functionality that DeepEquals uses. I'm 
> not a fan of Dump functions that just take an io.Writer. Why not add a 
> named type for interface{} or reflect.Value called reflect.Deep, which 
> implements fmt.Formatter? Then, packages that use fmt will have more 
> precise control over formatting, and we can maybe add special formatting 
> directives for reflect.Deep.
> >
> > What do you think?
>
> Well, we already have fmt.Printf("%#v", value).
>
> I don't see any obvious reason to add printing to the reflect package.
> It doesn't require any internal information, and can be written
> entirely separately. And, there will inevitably be a lot of desire
> for customization of the printed output, which will lead to a complex
> API.
>
> Basically: https://golang.org/doc/faq#x_in_std .
>
> 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/beda96b2-9f41-41f8-a501-3090b15ed37bn%40googlegroups.com.

[go-nuts] io/fs adapters?

[aind...@gmail.com]

For testing library functions that accept fs.FS, I've been creating mock FS 
implementations. However, I'm surprised by the amount of code I've had to 
write for something like an FS with a single file in it. See below:

*type singleFileFS struct {*
*f stringFile*
*}*

*func (r singleFileFS) Open(name string) (fs.File, error) { return nil, 
nil }*
*func (r singleFileFS) Stat(name string) (fs.FileInfo, error) { return r, 
nil }*
*func (r singleFileFS) Name() string  { return "." 
}*
*func (r singleFileFS) Size() int64   { return -1 }*
*func (r singleFileFS) Mode() (m fs.FileMode) { return }*
*func (r singleFileFS) ModTime() (t time.Time){ return }*
*func (r singleFileFS) IsDir() bool   { return true 
}*
*func (r singleFileFS) Sys() interface{}  { return nil 
}*
*func (r singleFileFS) ReadDir(string) ([]fs.DirEntry, error) { return 
[]fs.DirEntry{r.f}, nil }*
*func (r singleFileFS) ReadFile(name string) ([]byte, error)  { return 
r.f.body, nil }*

*type stringFile struct {*
*name string*
*body []byte*
*}*

*func (s stringFile) Stat() (fs.FileInfo, error)   { return s, nil }*
*func (s stringFile) Name() string { return s.name }*
*func (s stringFile) Size() int64  { return 
int64(len(s.body)) }*
*func (s stringFile) Mode() (m fs.FileMode){ return }*
*func (s stringFile) Type() (m fs.FileMode){ return }*
*func (s stringFile) ModTime() (t time.Time)   { return }*
*func (s stringFile) IsDir() (false bool)  { return }*
*func (s stringFile) Sys() (i interface{}) { return }*
*func (s stringFile) Read([]byte) (i int, e error) { return }*
*func (s stringFile) Close() (err error)   { return }*
*func (s stringFile) Info() (fs.FileInfo, error)   { return s, nil }*

Does anyone have any tips for creating a smaller version of this kind of 
adapter? Or are there any FS adapter libraries that can help with this sort 
of thing?

Thanks,
Akhil

-- 
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/aa307a2c-0569-4573-bb78-752713ff2a3dn%40googlegroups.com.

[go-nuts] Re: Difference between cmd/compile/internal/syntax/parser.go and pkg/go/parser/parser.go

[aind...@gmail.com]

I won't speak for the maintainers of cmd/compile/internal/syntax, but 
packages in the standard library have to be backwards compatible with 
previous releases. This makes it difficult to make changes to its interface 
(possibly for performance reasons) and major re-architectures of its 
implementation (like coupling it with other parts of cmd/compile).

On Saturday, March 27, 2021 at 8:07:38 PM UTC-4 philne...@gmail.com wrote:

> Hey folks,
>
> Why does Go reimplement the parser in pkg/go/parser on top of the one in 
> cmd/compile/internal? Why have two packages with somewhat duplicate code? 
> My guess is that it's easier to control what is public-public (available to 
> authors of Go programs) vs public within the compiler by having the partial 
> duplicate two packages?
>
> Happy for links if this question has been asked before.
>
> Thank you!
> Phil
>

-- 
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/449e9af7-0a02-47cc-b9a4-a5cd45f288a8n%40googlegroups.com.

[go-nuts] Re: io/fs adapters?

[aind...@gmail.com]

Thank you! I completely missed the memo on fstest :)

On Sunday, March 28, 2021 at 6:31:24 AM UTC-4 manlio@gmail.com wrote:

> For a project I wrote a simplified MapFS, where only the file data needs 
> to be specified, as a string:
> https://gist.github.com/perillo/45dfe7eb1c87e2d436574cab0d11221c
>
>
> Manlio
>
> Il giorno domenica 28 marzo 2021 alle 10:06:21 UTC+2 seank...@gmail.com 
> ha scritto:
>
>> https://pkg.go.dev/testing/fstest ?
>>
>> On Sunday, March 28, 2021 at 5:09:12 AM UTC+2 aind...@gmail.com wrote:
>>
>>> For testing library functions that accept fs.FS, I've been creating mock 
>>> FS implementations. However, I'm surprised by the amount of code I've had 
>>> to write for something like an FS with a single file in it. See below:
>>>
>>> *type singleFileFS struct {*
>>> *f stringFile*
>>> *}*
>>>
>>> *func (r singleFileFS) Open(name string) (fs.File, error) { return 
>>> nil, nil }*
>>> *func (r singleFileFS) Stat(name string) (fs.FileInfo, error) { return 
>>> r, nil }*
>>> *func (r singleFileFS) Name() string  { return 
>>> "." }*
>>> *func (r singleFileFS) Size() int64   { return 
>>> -1 }*
>>> *func (r singleFileFS) Mode() (m fs.FileMode) { return }*
>>> *func (r singleFileFS) ModTime() (t time.Time){ return }*
>>> *func (r singleFileFS) IsDir() bool   { return 
>>> true }*
>>> *func (r singleFileFS) Sys() interface{}  { return 
>>> nil }*
>>> *func (r singleFileFS) ReadDir(string) ([]fs.DirEntry, error) { return 
>>> []fs.DirEntry{r.f}, nil }*
>>> *func (r singleFileFS) ReadFile(name string) ([]byte, error)  { return 
>>> r.f.body, nil }*
>>>
>>> *type stringFile struct {*
>>> *name string*
>>> *body []byte*
>>> *}*
>>>
>>> *func (s stringFile) Stat() (fs.FileInfo, error)   { return s, nil }*
>>> *func (s stringFile) Name() string { return s.name 
>>> <http://s.name> }*
>>> *func (s stringFile) Size() int64  { return 
>>> int64(len(s.body)) }*
>>> *func (s stringFile) Mode() (m fs.FileMode){ return }*
>>> *func (s stringFile) Type() (m fs.FileMode){ return }*
>>> *func (s stringFile) ModTime() (t time.Time)   { return }*
>>> *func (s stringFile) IsDir() (false bool)  { return }*
>>> *func (s stringFile) Sys() (i interface{}) { return }*
>>> *func (s stringFile) Read([]byte) (i int, e error) { return }*
>>> *func (s stringFile) Close() (err error)   { return }*
>>> *func (s stringFile) Info() (fs.FileInfo, error)   { return s, nil }*
>>>
>>> Does anyone have any tips for creating a smaller version of this kind of 
>>> adapter? Or are there any FS adapter libraries that can help with this sort 
>>> of thing?
>>>
>>> Thanks,
>>> Akhil
>>>
>>

-- 
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/fcdf37ed-b43d-4632-a8e8-e3641c166c73n%40googlegroups.com.

[go-nuts] Should sync.Locker for sync.Once

[aind...@gmail.com]

I've often been in situations where I've wanted to store and error or some 
other signal once, but wanted reads to the stored value to be synchronized. 
I've often ended up introducing a secondary mutex, or reimplementing the 
slow path of sync.Once. This is a common pattern I see across many Go 
codebases, including the standard library for 
example: https://golang.org/src/io/pipe.go.

Given this, would it be beneficial for sync.Once to implement Locker? This 
would allow the mutex to be reused to synchronize access to the value being 
stored.

-- 
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/128ae959-8c71-431a-8960-fbdd57ad73dbn%40googlegroups.com.

[go-nuts] Re: Should sync.Locker for sync.Once

[aind...@gmail.com]

Argh I messed up the title. It should be "Should sync.Once implement 
sync.Locker?" Oh well...

On Friday, April 9, 2021 at 2:07:00 PM UTC-4 aind...@gmail.com wrote:

> I've often been in situations where I've wanted to store and error or some 
> other signal once, but wanted reads to the stored value to be synchronized. 
> I've often ended up introducing a secondary mutex, or reimplementing the 
> slow path of sync.Once. This is a common pattern I see across many Go 
> codebases, including the standard library for example: 
> https://golang.org/src/io/pipe.go.
>
> Given this, would it be beneficial for sync.Once to implement Locker? This 
> would allow the mutex to be reused to synchronize access to the value being 
> stored.
>

-- 
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/bdbf8e60-73b3-4703-bfa3-83eb15fd8f00n%40googlegroups.com.

[go-nuts] Re: text/template: Can't call method/function with 0 results.

[aind...@gmail.com]

I believe functions are meant to be used as part of a pipeline, so having
1 value (+ error) makes it so the pipeline only stops execution on an error.
I personally have not found a use for void functions, and it makes it easier
to visualize the template execution model.
On Friday, April 9, 2021 at 2:05:33 PM UTC-4 Johnny Jacobs wrote:

> Hello all,
>
> Is there any reason you can't use a custom function with no return value 
> in Go templates?
>
> You get a "Can't call method/function with 0 results." if you try to call 
> such a function. FuncMap  
> requires 
> functions to either return a value, or a value plus an error.
>
> Is there any reason, technical or otherwise, for these restrictions? 
> Variables assignment and many Action clauses don't give back values, so it 
> doesn't seem like it breaks convention.
>
> I might file an issue for this if nothing meaningful is brought up here.
>
> Best,
> Johnny
>

-- 
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/41190a31-3151-4a5a-b9b8-631198dca58fn%40googlegroups.com.

[go-nuts] Maps with non-comparable keys

[aind...@gmail.com]

Now that generics is coming along, is there an easy way to extend the 
builtin map type to use a non-comparable key type? For example, given this 
constraint

type Key[T any] interface {
Size() uint64
Hash(seed uint64) uint64
Equal(T) bool
}

and a type Foo like

type Foo []int
func (a Foo) Size() uint64 { ... }
func (a Foo) Hash(seed uint64) uint64 { ... }
func (a Foo) Equal(b Foo) bool { ... }

I'd like a map[Foo]struct{}. Is this possible now? Or does the runtime map 
have to be updated to support 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/a9296c66-7715-45ac-9fce-b1d3bc5b4343n%40googlegroups.com.

Re: [go-nuts] Maps with non-comparable keys

[aind...@gmail.com]

> I think it is unlikely to ever happen

Yeah, it'd require a language change wouldn't it? Still, it'd be nice to 
take advantage
of the runtime's map implementation without starting from scratch.

> I tried my hand at it for fun

Nice work! I like the use of map[uint64][]keyVal.


-- 
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/c1d3ea9e-c700-4f4b-a96d-0772c11f8fcdn%40googlegroups.com.

[go-nuts] Replicating C unions with unsafe, arrays, and some constant arithmetic

[aind...@gmail.com]

I found this trick recently to replicate a C union in Go with 
unsafe.Sizeof, arrays, and some constant arithmetic. This lets you 
stack-allocate data that needs to be the max size of multiple other data 
types. So given a type A and B that you want to union, you can say

const ASize = int64(unsafe.Sizeof(*new(A)))
const BSize = int64(unsafe.Sizeof(*new(B)))
const diff = ASize - BSize
const max = ASize - ((diff>>(bits.UintSize-1))&1)*diff

var storage [max]byte
*(*A)(unsafe.Pointer(&storage))
*(*B)(unsafe.Pointer(&storage))

This process can be repeated for any number of types. For example, if you 
wanted to represent a tagged union defined like

type A =
| B
| C int
| D (a: int, b: int)

you could lower it to something like

const size = int64(unsafe.Sizeof(*new(B)))
const size0 = int64(unsafe.Sizeof(*new(C)))
const diff = size - size0
const max = size - diff*((diff>>(bits.UintSize-1))&1)
const size1 = int64(unsafe.Sizeof(*new(D)))
const diff0 = size1 - max
const max0 = size1 - diff0*((diff0>>(bits.UintSize-1))&1)

type A struct {
tag uint8
storage [max0]byte
}
type B struct{}
type C int
type D struct {
a int
b int
}

Unfortunately, the resulting code is pretty inefficient compared to 
interfaces or struct embedding. It might be that the use of unsafe is 
hindering compiler optimizations, or maybe it's an alignment issue.

-- 
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/5d150c6a-3ecb-4cb8-91b3-c048940294aen%40googlegroups.com.