[go-nuts] Re: [ANN] peanut - write tagged structs to disk, in a variety of formats

[Jim Smart]

Oh — it also has a few writers that can be helpful during development and 
testing: swap the file writers for a log writer (or discard writer) during 
development (handy if your program usually spits out a lot of output 
files), and swap in the mock writer for easy testing.

/J
On Tuesday, April 20, 2021 at 9:49:04 PM UTC+1 Jim Smart wrote:

> Hi there fellow Go Nuts and Gophers,
>
> Whilst working on a project not long back, I created a library to easily 
> write tagged structs to disk, in a variety of output formats.
>
> https://github.com/jimsmart/peanut
>
> Each writer has a simple Write method, that takes a tagged struct. Each 
> type of struct is written to a separate file (or table), with 
> header/field/column names based upon the field tags. All writers use the 
> same tags.
>
> Currently peanut has writers for CSV/TSV, Excel (.xlsx), JSONL, and SQLite 
> — all of which share the same simple interface.
>
> One of the benefits of peanut is that, during development, one can just 
> focus on shape of the data records one is working with (and their 
> population), and not have to think about updating the code that writes the 
> data at all.
>
> Another benefit is that one can easily switch output formats, or indeed 
> support multiple output formats.
>
> It's also handy if one wishes to e.g. output an Excel file report for 
> management, summarising stats and metadata, at the end of a running task 
> (aside from other exported data).
>
> — Maybe this is useful to someone here?
>
> Regards,
> /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/8ca81933-f6ad-4522-a130-eb990a093399n%40googlegroups.com.

[go-nuts] [ANN] peanut - write tagged structs to disk, in a variety of formats

[Jim Smart]

Hi there fellow Go Nuts and Gophers,

Whilst working on a project not long back, I created a library to easily 
write tagged structs to disk, in a variety of output formats.

https://github.com/jimsmart/peanut

Each writer has a simple Write method, that takes a tagged struct. Each 
type of struct is written to a separate file (or table), with 
header/field/column names based upon the field tags. All writers use the 
same tags.

Currently peanut has writers for CSV/TSV, Excel (.xlsx), JSONL, and SQLite 
— all of which share the same simple interface.

One of the benefits of peanut is that, during development, one can just 
focus on shape of the data records one is working with (and their 
population), and not have to think about updating the code that writes the 
data at all.

Another benefit is that one can easily switch output formats, or indeed 
support multiple output formats.

It's also handy if one wishes to e.g. output an Excel file report for 
management, summarising stats and metadata, at the end of a running task 
(aside from other exported data).

— Maybe this is useful to someone here?

Regards,
/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/480a583b-e239-41e4-acae-55f6e967bcbcn%40googlegroups.com.

Re: [go-nuts] Trying to port Go to HPE NonStop x86 - Need some guidance

[Ian Lance Taylor]

On Tue, Apr 20, 2021 at 1:39 AM Shiva  wrote:
>
> I'm a bit confused now. Let me explain what I have been doing.
> 1. Installed go on windows (go version go1.4-bootstrap-20170531 windows/amd64)
> 2. Duped linux files to nsx and added build statements
> At this point, I am not supposed to run bootstrap.bash but run make.bat 
> because my installation is on windows. And when I ran make.bat, it failed 
> with the following error 'unknown $GOOS nsx', and the error was from 
> cmd\dist\build.c because it looks for known values in the okgoos array. And 
> there is no way for me to get past that if I use nsx, so I basically assumed 
> that I had to 'add support' for a new target OS. It was the same case with 
> sym.c. The only way I can make it work without updating these files would be 
> to use goos=linux, I assume.
>
> My goal has always been to get a cross-compiled version of go1.4 so that I 
> can move that to nsx and then compile the latest Go version on NSX. Please 
> let me know if I'm not on the right direction.

Sorry, but I don't think you're on the right direction.

There is no reason to ever port Go 1.4 to nsx.  The only reason we
talk about Go 1.4 at all is because it can be built without a
previously existing Go compiler.  But you have a previously existing
Go compiler: Go 1.16 (or any other release) on Windows.  Your goal
should be to port Go tip to nsx, not Go 1.4.  Once you've ported Go
tip to support nsx, then you can build it, on Windows, using Go 1.16
and bootstrap.bash.  That will give you a Go toolchain that will run
on nsx.

Porting Go 1.4 to nsx will be a lot of work that you will have to
completely redo in order to port Go tip.  What you want in the end is
Go tip, not Go 1.4.  So don't bother with Go 1.4 at all.

Ian



> On Monday, April 19, 2021 at 6:52:24 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Fri, Apr 16, 2021 at 2:28 AM Shiva  wrote:
>> >
>> > Since I haven't generated the various ztypes_nsx_GOARCH.go files, I think 
>> > I need to use +build nsx and not ignore the build for types_nsx.go.
>> >
>> > I found a way to run bootstrap.bat on windows but I was told that I had to 
>> > run make.bat instead, so I did. I had to add "nsx" to the array 'okgoos' 
>> > in cmd\dist\build.c to be able to run make.bat so I did that too. And the 
>> > output from make.bat had a lot of the same warning 'this statement may 
>> > fall through [-Wimplicit-fallthrough=]' and I ignored them. And I had to 
>> > update sym.c (liblink)'s headers array with an entry for nsx which made me 
>> > realise that the following files will need to have 'switch cases' for Hnsx 
>> > on a bunch of other asm*/obj files under cmd\*l and liblink. So I did them 
>> > too.
>> >
>> > I know that I also have to update cmd\ld\elf.c where I see three 
>> > references required for Hnsx - one at elfinit and the other two under 
>> > asmbelf function - one while setting interpreter and the other for setting 
>> > elf protected headers (?). But I'm uncertain about the changes required in 
>> > that file especially the one setting the interpreter because that requires 
>> > pointing to the dynamic linker loader (different ones for OABI and EABI) 
>> > in asm.c under cmd\*l directories? Can you please advise?
>>
>> I think you are on the wrong path here. The idea of using
>> bootstrap.bash is that you should not have to edit any of the Go 1.4 C
>> code at all. The idea is that you run bootstrap.bash on a system that
>> already has a working Go compiler installed. That working Go compiler
>> is then used as a cross-compiler to build a toolchain that will run on
>> nsx. That requires editing the Go tip code to support nsx. It does
>> not require editing any of the Go 1.4 code, and should not require
>> editing any C code at all.
>>
>> Ian
>>
>>
>> > On Wednesday, April 14, 2021 at 8:25:55 PM UTC+1 Ian Lance Taylor wrote:
>> >>
>> >> On Wed, Apr 14, 2021 at 8:25 AM Shiva  wrote:
>> >> >
>> >> > One file specifically, types_linux.go which I duped into types_nsx.go 
>> >> > has a build statement that goes like this '+build ignore'. Github 
>> >> > discussions around this suggest to me that I don't have to build this? 
>> >> > But happy to be corrected.
>> >>
>> >> The "+build ignore" line means that the file will not be built as part
>> >> of an ordinary "go build" or "go install". For a file like
>> >> syscall/types_linux.go, that is because the file originally served as
>> >> input to cgo -godefs as part of generating the various
>> >> ztypes_linux_GOARCH.go files.
>> >>
>> >> > Also, can I build the bootstrap on windows or can I only do it in a 
>> >> > POSIX environment - I don't see bootstrap.bat and running 
>> >> > bootstrap.bash with GOOS=nsx and GOARCH=amd64 simply returns back the 
>> >> > prompt?
>> >>
>> >> You should be able to build a bootstrap on Windows but you'll have to
>> >> either replicate bootstrap.bash in a Windows style, or you'll have to
>> >> use something like cygwin to run the bootstrap.bash shell script.
>> >

Re: [go-nuts] TotalAlloc dropped in runtime/metrics

['Michael Knyszek' via golang-nuts]

Oh, actually, you can compute Mallocs and Frees from allocs-by-size and
frees-by-size (summing the total # of samples). You can only estimate
TotalAlloc though, which is genuinely missing.

On Tue, Apr 20, 2021 at 3:14 PM Michael Knyszek  wrote:

> Oh gosh, I think TotalAlloc, Mallocs, and Frees are actually an oversight
> on my part. Sorry about that. They're very easy to add and I can probably
> even add them for this release.
>
> Please do use the new runtime/metrics package!
>
> Most of the other metrics should be there in some form (e.g. the divisions
> are a little different; they're meant to be more orthogonal to each
> other... GC pause latencies are now in a histogram) and new ones are going
> to be added in the next release and in the future. Also: today, it does not
> have the same stop-the-world penalty that ReadMemStats has, so I recommend
> it on that basis.
>
> On Tue, Apr 20, 2021 at 3:08 PM Ian Lance Taylor  wrote:
>
>> [ + mknyszek ]
>>
>> On Tue, Apr 20, 2021 at 11:12 AM Marco A.  wrote:
>> >
>> > Hi everyone,
>> >
>> > I was considering using the new stable metrics interface with go 1.16 (
>> https://golang.org/pkg/runtime/metrics/) for our program and I was also
>> wondering why things like TotalAlloc (
>> https://golang.org/pkg/runtime/#MemStats) had been dropped in the
>> available metrics.
>> >
>> > Any particular reasoning behind 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAFza%2Bu-E8yBaxOkvMrSLpPUcSzLjJedB_LcKhTQTxqhJuTMqgQ%40mail.gmail.com.

[go-nuts] Re: go build ./... will produce a binary of one and only one main package is found

[Manlio Perillo]

Il giorno martedì 20 aprile 2021 alle 21:26:33 UTC+2 Manlio Perillo ha 
scritto:

> Il giorno martedì 20 aprile 2021 alle 09:08:02 UTC+2 Brian Candler ha 
> scritto:
>
>> I agree with the OP: it would be less surprising if "go build ./..." 
>> always did build and store the artefacts, and there were a separate flag to 
>> discard them.
>>
>> Currently, "go build ./..." discards the build artefacts under certain 
>> conditions, see this example 
>> .
>>
>
> You can discard build artifacts with `go build -o /dev/null ./...`.  This 
> is not documented and works thanks to
> https://golang.org/cl/31657.
>
>
And I notice only now that you can do `go build -o "" ./...`.

Manlio

-- 
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/f76ed6d6-8edd-4132-a382-ab693e0bb69en%40googlegroups.com.

[go-nuts] Re: go build ./... will produce a binary of one and only one main package is found

[Manlio Perillo]

Il giorno martedì 20 aprile 2021 alle 09:08:02 UTC+2 Brian Candler ha 
scritto:

> I agree with the OP: it would be less surprising if "go build ./..." 
> always did build and store the artefacts, and there were a separate flag to 
> discard them.
>
> Currently, "go build ./..." discards the build artefacts under certain 
> conditions, see this example 
> .
>

You can discard build artifacts with `go build -o /dev/null ./...`.  This 
is not documented and works thanks to
https://golang.org/cl/31657.

Manlio 

-- 
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/3b652379-242a-4287-b4d1-934cfd374965n%40googlegroups.com.

Re: [go-nuts] TotalAlloc dropped in runtime/metrics

['Michael Knyszek' via golang-nuts]

Oh gosh, I think TotalAlloc, Mallocs, and Frees are actually an oversight
on my part. Sorry about that. They're very easy to add and I can probably
even add them for this release.

Please do use the new runtime/metrics package!

Most of the other metrics should be there in some form (e.g. the divisions
are a little different; they're meant to be more orthogonal to each
other... GC pause latencies are now in a histogram) and new ones are going
to be added in the next release and in the future. Also: today, it does not
have the same stop-the-world penalty that ReadMemStats has, so I recommend
it on that basis.

On Tue, Apr 20, 2021 at 3:08 PM Ian Lance Taylor  wrote:

> [ + mknyszek ]
>
> On Tue, Apr 20, 2021 at 11:12 AM Marco A.  wrote:
> >
> > Hi everyone,
> >
> > I was considering using the new stable metrics interface with go 1.16 (
> https://golang.org/pkg/runtime/metrics/) for our program and I was also
> wondering why things like TotalAlloc (
> https://golang.org/pkg/runtime/#MemStats) had been dropped in the
> available metrics.
> >
> > Any particular reasoning behind 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAFza%2Bu954NiVW63%3DwGQD-97jXdats6UAB9p%2BrpiZHrLYP4EbRA%40mail.gmail.com.

Re: [go-nuts] TotalAlloc dropped in runtime/metrics

[Ian Lance Taylor]

[ + mknyszek ]

On Tue, Apr 20, 2021 at 11:12 AM Marco A.  wrote:
>
> Hi everyone,
>
> I was considering using the new stable metrics interface with go 1.16 
> (https://golang.org/pkg/runtime/metrics/) for our program and I was also 
> wondering why things like TotalAlloc 
> (https://golang.org/pkg/runtime/#MemStats) had been dropped in the available 
> metrics.
>
> Any particular reasoning behind 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVaOn6QaP7uaxi27e4-mHc%2BiK-QZw%2B0CNbT%2Bf4zdnOdfA%40mail.gmail.com.

Re: [go-nuts] Re: help with the Google Pub/Sub Go client API

['hong...@google.com' via golang-nuts]

Ack. Yeah, I totally agree with some of your points. I'll create a tracking 
issue to improve the comments and the docs. Thanks a ton for the feedback!

On Monday, April 19, 2021 at 4:10:14 PM UTC-7 kortschak wrote:

> Comments in-line.
>
> On Mon, 2021-04-19 at 15:08 -0700, 'hong...@google.com' via golang-nuts
> wrote:
> > Ah, glad your issue was resolved. I did want to point out one thing:
> >
> > > 2. The topic was obtained in the subscriber using new topic
> > creation
> > > `client.CreateTopic(ctx, topic)` rather than getting a topic
> > reference
> > > `client.Topic(topic)` which I see now is incorrect (thought which
> > is
> > > poorly explained in the documentation).
> >
> > Getting the topic via `create.CreateTopic` or `client.Topic` should
> > work
> > for subscriber creation. Both return `pubsub.Topic` struct[1], which
> > can
> > be used to call `topic.Publish` and pass to subscription config.
> > I quickly tested this to confirm, code here[2].
>
> If I make this change to github.com/kortschak/scheduler
> ```
> index 6f62da8..8f3fb87 100644
> --- a/listener/main.go
> +++ b/listener/main.go
> @@ -133,7 +133,11 @@ topics should be subscribed to using the default 
> subscription config.
> log.Printf("using default config: %v", cfg.DefaultConfig)
> subConfig = cfg.DefaultConfig
> }
> - subConfig.Topic = client.Topic(sub.Topic)
> + t, err := client.CreateTopic(ctx, sub.Topic)
> + if err != nil {
> + log.Fatalf("failed to create topic %q: %v", sub.Topic, err)
> + }
> + subConfig.Topic = t
> s, err := client.CreateSubscription(ctx, sub.ID, subConfig)
> if err != nil {
> if grpc.Code(err) == codes.AlreadyExists {
> ```
>
> I see this error when I run scheduler and listener.
>
> ```
> 2021/04/20 08:02:58 available topics:
> 2021/04/20 08:02:58 projects/testing/topics/cron-job
> 2021/04/20 08:02:58 projects/testing/topics/cron-job-again
> 2021/04/20 08:02:58 subscribing to "cron-job" as "test-0"
> 2021/04/20 08:02:58 failed to create topic "cron-job": rpc error: code
> = AlreadyExists desc = Topic already exists
> exit status 1
> ```
> The issue here is that the topic has already been created by the
> publisher. This is where greater contextual information in the docs
> would be helpful. My reading of the docs for *Client.Topic, "Topic
> creates a reference to a topic in the client's project", was that there
> would already have to be a *pubsub.Topic and that that would be *local*
> (this last bit is not true — it was influenced by notions of file
> references). Unfortunately the terseness of the docs don't help here.
>
>
> > Lastly, with regards to the cmdline examples, I'm guessing this was
> > removed because we had the official gcloud sdk `gcloud pubsub ...`.
> > Although the gcloud sdk doesn't use the Go client, I think we didn't
> > think it would be necessary to support two API surfaces.
>
> My suggestion was not for use as a client, but as an integrated
> example.
>
>
> > We do keep our code samples in our golang-samples[3] repo,
> > and I'm not sure if it was these samples that you found were
> > hard to navigate,
>
> It's not that they are hard to navigate, the docs in
> https://cloud.google.com/pubsub/docs/samples is very navigable, it's
> just that the scale of the context for them is not very useful being
> only slightly larger scale than a reader would get from the godoc. The
> context could be improved either by reducing the terseness of the godoc
> (for example saying for *Client.CreateTopic that *Client.Topic should
> be used if the *Topic has already been created), or by providing actual
> runnable examples in the form of example tests, which pkg.go.dev does a
> reasonably good job of turning into main packages.
>
>
> > but if so, we're very much open to feedback. I think I can sort of
> > see your point of how the cmdline example is easier to read (with it
> > being all in one file), but it's part of the repo's style to keep
> > code samples in separate files.
>
> It's not so much that they are separate files, but rather that there is
> little contextual information showing how they should be composed.
>
>
> > For learning, I'll work on adding a more comprehensive end-to-end
> > guide that lives in the package docs instead.
>
> Yes, I think this would be a good way to go. It doesn't need to be
> extensive, just hitting a reasonable set of common compositions and
> uses.
>
> thanks
> Dan
>
> > [1] https://pkg.go.dev/cloud.google.com/go/pubsub#Topic
> > [2] https://play.golang.org/p/Vpe6RxP6Db3
> > [3]
> > https://github.com/GoogleCloudPlatform/golang-samples/tree/master/pubsub
>
>
>
>

-- 
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/f09b1f2c-5736-4ede-bf5e-6546db2f676en%40googlegroups.com.

[go-nuts] TotalAlloc dropped in runtime/metrics

[Marco A.]

Hi everyone,

I was considering using the new stable metrics interface with go 1.16 
(https://golang.org/pkg/runtime/metrics/) for our program and I was also 
wondering why things like TotalAlloc 
(https://golang.org/pkg/runtime/#MemStats) had been dropped in the 
available metrics.

Any particular reasoning behind 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/c12d3534-d0b3-4567-9bc8-7cdcfb63c23cn%40googlegroups.com.

[go-nuts] [ANN] go-portable and go-compatible

[Manlio Perillo]

Recently I have started to send some CL to the Go project, and I wanted 
some tools to check the portability to other platforms and the 
compatibility to older Go releases of my changes.

https://github.com/perillo/go-portable checks if a package is portable to 
all the platforms supported by go.  Internally it invokes go vet on all the 
platforms listed by go tool dist list.
With the -first-class option, it is possible to limit the use to only first 
class ports.

https://github.com/perillo/go-compatible checks if a package is compatible 
with older versions of go.  Internally it invokes go vet on all the 
releases in ~/sdk.
With the -since option, it is possible to limit the use to to only releases 
more recent than the specified version.
With the -test option, the tool invokes go test, instead of go vet.

Regards
Manlio Perillo

-- 
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/b1c0e02f-7e1a-495b-8757-553d8dba238bn%40googlegroups.com.

Re: [go-nuts] Trying to port Go to HPE NonStop x86 - Need some guidance

[Shiva]

Ian,

I'm a bit confused now. Let me explain what I have been doing. 
1. Installed go on windows (go version go1.4-bootstrap-20170531 
windows/amd64)
2. Duped linux files to nsx and added build statements
At this point, I am not supposed to run bootstrap.bash but run make.bat 
because my installation is on windows. And when I ran make.bat, it failed 
with the following error 'unknown $GOOS nsx', and the error was from 
cmd\dist\build.c because it looks for known values in the okgoos array. And 
there is no way for me to get past that if I use nsx, so I basically 
assumed that I had to 'add support' for a new target OS. It was the same 
case with sym.c. The only way I can make it work without updating these 
files would be to use goos=linux, I assume. 

My goal has always been to get a cross-compiled version of go1.4 so that I 
can move that to nsx and then compile the latest Go version on NSX. Please 
let me know if I'm not on the right direction. 

Shiva
On Monday, April 19, 2021 at 6:52:24 PM UTC+1 Ian Lance Taylor wrote:

> On Fri, Apr 16, 2021 at 2:28 AM Shiva  wrote:
> >
> > Since I haven't generated the various ztypes_nsx_GOARCH.go files, I 
> think I need to use +build nsx and not ignore the build for types_nsx.go.
> >
> > I found a way to run bootstrap.bat on windows but I was told that I had 
> to run make.bat instead, so I did. I had to add "nsx" to the array 'okgoos' 
> in cmd\dist\build.c to be able to run make.bat so I did that too. And the 
> output from make.bat had a lot of the same warning 'this statement may fall 
> through [-Wimplicit-fallthrough=]' and I ignored them. And I had to update 
> sym.c (liblink)'s headers array with an entry for nsx which made me realise 
> that the following files will need to have 'switch cases' for Hnsx on a 
> bunch of other asm*/obj files under cmd\*l and liblink. So I did them too.
> >
> > I know that I also have to update cmd\ld\elf.c where I see three 
> references required for Hnsx - one at elfinit and the other two under 
> asmbelf function - one while setting interpreter and the other for setting 
> elf protected headers (?). But I'm uncertain about the changes required in 
> that file especially the one setting the interpreter because that requires 
> pointing to the dynamic linker loader (different ones for OABI and EABI) in 
> asm.c under cmd\*l directories? Can you please advise?
>
> I think you are on the wrong path here. The idea of using
> bootstrap.bash is that you should not have to edit any of the Go 1.4 C
> code at all. The idea is that you run bootstrap.bash on a system that
> already has a working Go compiler installed. That working Go compiler
> is then used as a cross-compiler to build a toolchain that will run on
> nsx. That requires editing the Go tip code to support nsx. It does
> not require editing any of the Go 1.4 code, and should not require
> editing any C code at all.
>
> Ian
>
>
> > On Wednesday, April 14, 2021 at 8:25:55 PM UTC+1 Ian Lance Taylor wrote:
> >>
> >> On Wed, Apr 14, 2021 at 8:25 AM Shiva  wrote:
> >> >
> >> > One file specifically, types_linux.go which I duped into types_nsx.go 
> has a build statement that goes like this '+build ignore'. Github 
> discussions around this suggest to me that I don't have to build this? But 
> happy to be corrected.
> >>
> >> The "+build ignore" line means that the file will not be built as part
> >> of an ordinary "go build" or "go install". For a file like
> >> syscall/types_linux.go, that is because the file originally served as
> >> input to cgo -godefs as part of generating the various
> >> ztypes_linux_GOARCH.go files.
> >>
> >> > Also, can I build the bootstrap on windows or can I only do it in a 
> POSIX environment - I don't see bootstrap.bat and running bootstrap.bash 
> with GOOS=nsx and GOARCH=amd64 simply returns back the prompt?
> >>
> >> You should be able to build a bootstrap on Windows but you'll have to
> >> either replicate bootstrap.bash in a Windows style, or you'll have to
> >> use something like cygwin to run the bootstrap.bash shell script.
> >> There aren't that many real commands in bootstrap.bash so I think that
> >> creating a minimal bootstrap.bat would be fairly simple.
> >>
> >> 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/420ce2be-b241-435f-89f9-b5f7c121bb9an%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3e8a31b9-f349-4984-8538-df7533fccb36n%40googlegroups.com.

[go-nuts] Re: go build ./... will produce a binary of one and only one main package is found

[Brian Candler]

I agree with the OP: it would be less surprising if "go build ./..." always 
did build and store the artefacts, and there were a separate flag to 
discard them.

Currently, "go build ./..." discards the build artefacts under certain 
conditions, see this example 
.

-- 
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/23ac5402-3010-4c8b-858a-aee6c0300816n%40googlegroups.com.