date:20230303

[go-nuts] Re: Correctly tagging a module in a subdirectory of a Github repo

2023-03-03 Thread Jim Idle

Just to follow up on my question, I have read all the docs again, and I am 
thinking that I used the wrong tag syntax. I think it should either be:

git tag -a  runtime/Go/antlr/v4/v4.12.0 -m "ssads" runtime/Go/antlr/v4

or just

git tag -a  runtime/Go/antlr/v4/v4.12.0 -m "ssads"

Am I on the right path?

Sorry to speculate here on the group, but I cannot just go start messing 
around on the master branch and testing it out, or I would have done so.

Jim

On Saturday, March 4, 2023 at 12:09:48 PM UTC+8 Jim Idle wrote:

> For historic reasons, which are too difficult to change (and pre-modules), 
> the runtime module for the ANTLR v4 Go runtime is held in a subdirectory of 
> the antlr/antlr4 Github repo. This is complicated by the fact that 
> organizations have written scripts into their build to copy the source code 
> into their monorepos and so on (I'm looking at you Google ;). I cannot just 
> put the source code into its own repo and be done with it. Also, there are 
> a ton of automated scripts for testing and release etc. There are something 
> like 45 projects within Google alone that rely on the source location and 
> tag presence etc.
>
> In the past, tags with the v prefix had been created that point to the 
> root of the repo (to clarify, I mean the tags don't contain the prefix - I 
> know tags point at commit hashes). They were not created for go and people 
> have used them in builds - I cannot just delete them. For instance, there 
> is a tag v.4.11.1 which seemed to totally throw off the go get etc and 
> while using the path to the runtime in the import works, it meant that the 
> entire repo source is installed as if it were the go module, and the go.mod 
> for a project and the ~/go/pkg/mod shows 
> github.com/antlr/ant...@v4.11.1+incompatible 
> . I can understand 
> why this is.
>
> With the latest release v4.12.0, I created tags with the directory prefix: 
> runtime/Go/antlr/v4/v4.12.0 a la:
>
> git tag -a v4.12.0 -m "ssads" runtime/Go/antlr/v4
>
> And there is no v4.12.0 tag. There is a 4.12.0 tag for use by non-go users 
> in the future.
>
> This seems to work in that the cache now only contains the v4 source for 
> go. So far so good. But when a go get is issued, the go.mod (and reflected 
> in cache) for a project seems to indicate the commit hash and not the 
> version, so the module for a project that uses it will look like this:
>
> module x/y/z
>
> go 1.19
>
> require (
> github.com/antlr/antlr4/runtime/Go/antlr/v4 
> v4.0.0-20230219212500-1f9a474cc2dc
> )
>
> require golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2 // indirect
>
> Where I was expecting to see v4.12.0. The go.mod for the runtime is stored 
> inthe /v4 directory of course, but there is no other go.mod, such as at the 
> root of the repo.
>
> The docs are a little light on this area, so I cannot tell if this is what 
> should be expected, or whether my tags are not quite correct in some way.
>
> The current latest tag is:
>
>
> https://github.com/antlr/antlr4/releases/tag/runtime%2FGo%2Fantlr%2Fv4%2Fv4.12.0
>
> The previous incorrect tag is:
>
> https://github.com/antlr/antlr4/releases/tag/v4.11.1
>
> I suspect that the directory associated tag is not correct, and that:
>
> go get -u github.com/antlr/antlr4/runtime/Go/antlr/v4
>
> Is just getting the latest commit to master, or the commit at the point 
> where the tag was created. I am aware that tags point at the commit and 
> refer to the repo as a whole. I'm even looking suspiciously at that 
> uppercase G.
>
> I suspect this because:
>
> go get -u github.com/antlr/antlr4/runtime/Go/antlr/v...@v4.12.0 
> 
> go: github.com/antlr/antlr4/runtime/Go/antlr/v...@v4.12.0 
> : invalid 
> version: unknown revision runtime/Go/antlr/v4.12.0
>
> So, I am wondering if there are any devops guys on here (I am a wizened 
> old coder, used to having devops guys to ask ;), that no how to do this 
> correctly?
>
> Any pointers appreciated. Hopefully I am just misunderstanding something 
> here.
>
> Jim
>

-- 
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/2f38c23d-48b0-4b25-847f-7b6131b7c372n%40googlegroups.com.

[go-nuts] Correctly tagging a module in a subdirectory of a Github repo

2023-03-03 Thread Jim Idle

For historic reasons, which are too difficult to change (and pre-modules),
the runtime module for the ANTLR v4 Go runtime is held in a subdirectory of
the antlr/antlr4 Github repo. This is complicated by the fact that
organizations have written scripts into their build to copy the source code
into their monorepos and so on (I'm looking at you Google ;). I cannot just
put the source code into its own repo and be done with it. Also, there are
a ton of automated scripts for testing and release etc. There are something
like 45 projects within Google alone that rely on the source location and
tag presence etc.

In the past, tags with the v prefix had been created that point to the root
of the repo (to clarify, I mean the tags don't contain the prefix - I know
tags point at commit hashes). They were not created for go and people have
used them in builds - I cannot just delete them. For instance, there is a
tag v.4.11.1 which seemed to totally throw off the go get etc and while
using the path to the runtime in the import works, it meant that the entire
repo source is installed as if it were the go module, and the go.mod for a
project and the ~/go/pkg/mod shows
github.com/antlr/antlr4@v4.11.1+incompatible. I can understand why this is.

With the latest release v4.12.0, I created tags with the directory prefix:
runtime/Go/antlr/v4/v4.12.0 a la:

git tag -a v4.12.0 -m "ssads" runtime/Go/antlr/v4

And there is no v4.12.0 tag. There is a 4.12.0 tag for use by non-go users
in the future.

This seems to work in that the cache now only contains the v4 source for
go. So far so good. But when a go get is issued, the go.mod (and reflected
in cache) for a project seems to indicate the commit hash and not the
version, so the module for a project that uses it will look like this:

module x/y/z

go 1.19

require (
github.com/antlr/antlr4/runtime/Go/antlr/v4
v4.0.0-20230219212500-1f9a474cc2dc
)

require golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2 // indirect

Where I was expecting to see v4.12.0. The go.mod for the runtime is stored
inthe /v4 directory of course, but there is no other go.mod, such as at the
root of the repo.

The docs are a little light on this area, so I cannot tell if this is what
should be expected, or whether my tags are not quite correct in some way.

The current latest tag is:

https://github.com/antlr/antlr4/releases/tag/runtime%2FGo%2Fantlr%2Fv4%2Fv4.12.0

The previous incorrect tag is:

https://github.com/antlr/antlr4/releases/tag/v4.11.1

I suspect that the directory associated tag is not correct, and that:

go get -u github.com/antlr/antlr4/runtime/Go/antlr/v4

Is just getting the latest commit to master, or the commit at the point
where the tag was created. I am aware that tags point at the commit and
refer to the repo as a whole. I'm even looking suspiciously at that
uppercase G.

I suspect this because:

go get -u github.com/antlr/antlr4/runtime/Go/antlr/v4@v4.12.0
go: github.com/antlr/antlr4/runtime/Go/antlr/v4@v4.12.0: invalid version:
unknown revision runtime/Go/antlr/v4.12.0

So, I am wondering if there are any devops guys on here (I am a wizened old
coder, used to having devops guys to ask ;), that no how to do this
correctly?

Any pointers appreciated. Hopefully I am just misunderstanding something
here.

Jim

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

[go-nuts] Re: alignment of stack-allocated variables?

2023-03-03 Thread 'Keith Randall' via golang-nuts

If you're using unsafe anyway, I'd go the other direction, casting from the 
larger alignment to the smaller one. That avoids any alignment concerns.

var x uint32
b := (*[4]byte)(unsafe.Pointer())[:]
r.buff.Read(b)
return x

I would encourage you to use encoding/binary though. It all works out just 
as well without unsafe, with a bit of trickiness around making sure that 
calls can be resolved and inlined.

b := make([]byte, 4)
buf.Read(b)
if little { // some global variable (or constant) you set
   return binary.LittleEndian.Uint32(b)
}
return binary.BigEndian.Uint32(b)
On Friday, March 3, 2023 at 12:30:37 PM UTC-8 TheDiveO wrote:

> In dealing with Linux netlink messages I need to decode and encode uint16, 
> uint32, and uint64 numbers that are in an arbitrary aligned byte buffer in 
> an arbitrary position. In any case, these numbers are in native endianess, 
> so I would like to avoid having to go through encoding/binary.
>
> buff := bytes.NewBuffer(/* some data */)
>
> // ...
>
> func foo() uint32 {
> var s struct {
> _ [0]uint32
> b [4]byte
> }
> r.buff.Read(s.b[:])
> return *(*uint32)(unsafe.Pointer([0]))
> }
>
> Will the go compiler (1.19+) allocate on the stack with the correct 
> alignment for its element b, so that the unsafe.Pointer operation correctly 
> works on different CPU architectures?
>
> Or is this inefficient anyway in a subtle way that my attempt to avoid 
> non-stack allocations is moot anyway?
>

-- 
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/7b241c86-3295-4488-888c-1beb467dd1b1n%40googlegroups.com.

[go-nuts] alignment of stack-allocated variables?

2023-03-03 Thread TheDiveO

In dealing with Linux netlink messages I need to decode and encode uint16, 
uint32, and uint64 numbers that are in an arbitrary aligned byte buffer in 
an arbitrary position. In any case, these numbers are in native endianess, 
so I would like to avoid having to go through encoding/binary.

buff := bytes.NewBuffer(/* some data */)

// ...

func foo() uint32 {
var s struct {
_ [0]uint32
b [4]byte
}
r.buff.Read(s.b[:])
return *(*uint32)(unsafe.Pointer([0]))
}

Will the go compiler (1.19+) allocate on the stack with the correct 
alignment for its element b, so that the unsafe.Pointer operation correctly 
works on different CPU architectures?

Or is this inefficient anyway in a subtle way that my attempt to avoid 
non-stack allocations is moot anyway?

-- 
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/ea8e7801-6caf-466b-8543-cfccfc76dd02n%40googlegroups.com.

[go-nuts] Generic Wrappers that do reflection on Initialization

2023-03-03 Thread Peter Müller

Hello, would you assess the following usage of  `Var[T any]`, `v = 
new(Var[T])` and `var person = rel.NewVar[Person]("person")` as valid 
pattern, that also enables it to be used in further generic methods, or 
would you rather prefer a codegen approach?

```go
type Var[T any] struct {
name   string
attributeNames []string
typreflect.Type
}

func NewVar[T any](name string) (v *Var[T]) {
v = new(Var[T])
v.name = name

var typ *T
v.typ = reflect.TypeOf(typ).Elem()
v.attributeNames = make([]string, v.typ.NumField())
for i := 0; i < v.typ.NumField(); i++ {
v.attributeNames[i] = v.typ.Field(i).Tag.Get("db")
}

return v
}
```

Example:


```go
import "github.com/peter-mueller/rel"

type Person struct {
Name string `db:"name"`
Age  int`db:"age"`
}

var personRel = rel.NewVar[Person]("person")

func InsertGeneric[T any](v *rel.Var[T], value T) (stmt string, params 
[]any) {
stmt += fmt.Sprintf("INSERT INTO %s (%s)\n", v.Name(), 
strings.Join(v.AttributeRef(), ", "))
stmt += fmt.Sprintf("VALUES (%s)\n", strings.Join(v.Params("?"), ","))
params = v.Tuple(value)
return stmt, params
}

// compiler checks if a Person struct is inserted into the relvar 
stmt, params := InsertGeneric(personRel, Person{"Ann", 21})
res, err := db.ExecContext(ctx, stmt, params...)
```

I think a non-generic alternative use would be to pass a empty struct 
value, but then the compiler can't check the types on inserts :

```go
var personRel = rel.NewVar("person", Person{})
Insert(personRel, Person{"Ann", 21})
Insert(personRel, 12)
```

-- 
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/e3db4eef-13a7-4a3c-9b00-0027bab79aban%40googlegroups.com.

[go-nuts] Re: Nested structs

2023-03-03 Thread Brian Candler

Use pointers.

https://go.dev/play/p/V9M_XxX052J

On Friday, 3 March 2023 at 13:18:30 UTC BARIKUMA MONDELO wrote:

> Is it possible to have two structs both declared in each other, something 
> like this
>
> type human struct {
> name string
> age int
> address Address
> }
>
> type Address struct {
> country, city string
> postalCode uint
> human
> }
>

-- 
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/eb65bc25-6b3d-4bbb-80d3-af9bd18b3400n%40googlegroups.com.

[go-nuts] Nested structs

2023-03-03 Thread BARIKUMA MONDELO

Is it possible to have two structs both declared in each other, something
like this

type human struct {
name string
age int
address Address
}

type Address struct {
country, city string
postalCode uint
human
}

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

[go-nuts] Re: heap profiling does not work on M2 MacBook air?

2023-03-03 Thread Jochen Voss

Hi Peter,

Thanks again for looking into this, and for your help!

You mention that the blog post was long ago.  I wonder whether the code to 
write profile information is covered by the compatibility promise.  If so, 
probably the legacy WriteHeapProfile function could be made to implement 
the required code to keep this working.  Should a bug report be filed to 
this effect? 

Similarly, should a bug report be filed about the mistake you found in the 
pprof package documentation?

All the best,
Jochen
On Thursday, 2 March 2023 at 15:36:24 UTC peterGo wrote:

> On Thursday, March 2, 2023 at 2:03:22 AM UTC-5 Jochen Voss wrote:
>
> Hi Peter,
>
> Thanks a lot, giving the "-alloc_space" option makes all the difference!  
> With this option, it also works for me.
>
> I wonder whether it meant to be the way that you have to give this 
> option.  Maybe something broke?  In the blog entry 
> https://go.dev/blog/pprof they didn't need this option to get the profile 
> output.
>
>
> The Go blog post at https://go.dev/blog/pprof was written in 2011; it is 
> now 2023. For up-to-date information, see the latest pprof package 
> documentation at https://pkg.go.dev/runtime/pprof@latest.
>
> The pprof package documentation is incorrect: 
>
> To add equivalent [go test] profiling support to a standalone program, add 
> code like the following to your main function:
>
> // ...
> runtime.GC() // get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> log.Fatal("could not write memory profile: ", err)
> }
> // ...
>
> To obtain equivalent results, replace the above code with:
>
> // ...
> runtime.GC() // get up-to-date statistics
> if allocs := pprof.Lookup("allocs"); allocs == nil {
> log.Fatal("could not lookup memory profile: ")
> } else if err := allocs.WriteTo(f, 0); err != nil {
>
> log.Fatal("could not write memory profile: ", err)
> }
> // ...
>
> For your example,
>
> yyy.go: https://go.dev/play/p/epy4c3et1Io
>
> $ go build yyy.go && ./yyy
> $ go tool pprof mem.prof
> File: yyy
> Type: alloc_space
> Time: Mar 2, 2023 at 10:02am (EST)
>
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top
> Showing nodes accounting for 6975.42MB, 98.93% of 7050.77MB total
> Dropped 62 nodes (cum <= 35.25MB)
>
> Showing top 10 nodes out of 18
>   flat  flat%   sum%cum   cum%
>  3564.88MB 50.56% 50.56%  3564.88MB 50.56%  
> golang.org/x/exp/slices.Insert[.. 
> .] (inline)
>  3122.14MB 44.28% 94.84%  3122.14MB 44.28%  
> seehuhn.de/go/layout.(*Skip).Minus
>   117.01MB  1.66% 96.50%   117.01MB  1.66%  
> seehuhn.de/go/layout.(*Skip).Clone (inline)
>   115.51MB  1.64% 98.14%  6919.54MB 98.14%  
> seehuhn.de/go/layout.(*knuthPlassLineBreaker).Run
>52.89MB  0.75% 98.89%65.63MB  0.93%  compress/flate.NewWriter
> 2.50MB 0.035% 98.92%  6926.54MB 98.24%  
> seehuhn.de/go/layout.(*Engine).EndParagraph
> 0.50MB 0.0071% 98.93%  7050.27MB   100%  main.main
>  0 0% 98.93%65.63MB  0.93%  compress/flate.NewWriterDict
>  0 0% 98.93%65.63MB  0.93%  compress/zlib.(*Writer).Write
>  0 0% 98.93%65.63MB  0.93% 
>  compress/zlib.(*Writer).writeHeader
> (pprof) quit
> $ 
>
> Peter
>
>

-- 
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/a06065fb-ae57-4c52-b182-b444e9e32bcdn%40googlegroups.com.

[go-nuts] Re: Correctly tagging a module in a subdirectory of a Github repo

[go-nuts] Correctly tagging a module in a subdirectory of a Github repo

[go-nuts] Re: alignment of stack-allocated variables?

[go-nuts] alignment of stack-allocated variables?

[go-nuts] Generic Wrappers that do reflection on Initialization

[go-nuts] Re: Nested structs

[go-nuts] Nested structs

[go-nuts] Re: heap profiling does not work on M2 MacBook air?

8 matches

Site Navigation

Mail list logo

Footer information