[go-nuts] cryptic multiple roots error (in relation to plugins, -buildmode=shared, -linkshared)

[Basile Starynkevitch]

Hello All,

This *package, files at build (in relation to plugins, -linkshared, 
-buildmode=shared, )* thread ,  and that *plugins 
(Go 1.8) and packages* one 
, and the 
older *"multiple roots" error with 'go install buildmode=shared'* one 
 
(by Aaron Beitch)

The context

In my monimelt  project on github 
(for Linux x86-64 with Go 1.8), I want to generate Go code at runtime, for 
the Go compiler at runtime, and load it as plugins (all that in the same 
process; I did that in GCC MELT  for C++ code). 
Ideally (I am very far from that) I would like it to become a bootstrapped 
compiler  of 
some language (I am inventing) with my compiler (or transpiler) generating 
Go code. Ideally (I am very far from that), it would become (also) a Quine 
 prorgram.

The first step would be to store in some (Sqlite3) database something 
translatable to several plugin code. So I would like to have:

a main program P0 able to load many objects from Sqlite3; I believe I 
already have it.

an ordered sequence of plugins, P1, P2, ... Pn where all plugins (actually 
their Go code is generated at runtime) can import some packages provided by 
the main program P0, plugin  P2 can also use, ie import, some package 
provided by plugin P1,
plugin P3 can also use, i.e. import, packages from P1 and from P2,  and 
plugin Pi can use packages from any Pj with j < i.

So I need most of the code to be shareable. In an ideal world, I would like 
to forbid static unshared code in all my Go installation. I know that this 
is against the default rules of Go (which sadly prefers static linking; but 
recent Go fortunately have -buildmode=shared and -linkshared options to 
overcome that; I will use them *systematically*).

So I understood that I first need (once and for all after a pristine Go 
installation) to run go install -buildmode=shared std and I know how to 
check that it has been run.

Then, every other package (either an external one, like go-sqlite3, or 
mine) that I will compile needs to be compiled with both -buildmode=shared 
and -linkshared options.


Cryptic *multiple roots* error

I quite often get the *cryptic *

multiple roots /home/basile/go/pkg/linux_amd64 & /usr/local/go/pkg/
linux_amd64

message (I believe *that message is very confusing* and would merit an 
entire wikipage to explain it; I also believe that the error message itself 
should be improved to suggest corrective actions) For what it is worth, 
/home/basile/go is my default GOPATH, and /usr/local/go is my default 
GOROOT. And I am getting that message depending on past history of previous 
commands. So to debug it, I quite often remove all my Go subsystem (by 
running rm -rf $HOME/go /usr/local/go then improving my $PATH, or adding 
there appropriate symlinks for the go, gofmt, godoc programs to e.g. 
/usr/local/bin which is in my $PATH), reinstall it, and repeat and that 
is *very* time consuming.

Ian Taylor kindly explained me that multiple roots is about:

That error message means that the go tool does not know where to 
> install a file.  It may mean that you are trying to use 
> -buildmode=shared with some standard library packages and some 
> packages from your GOPATH.  It's not a conflict between different 
> files; it's talking about which directory it should put the shared 
> library in
>

But I don't understand how to avoid it. Is there some option or some way to 
say to Go that I want the binary package to be written under GOPATH and not 
under GOROOT; or to force the subtree in which there are written.

A simplified way to ask my questions

I believe I can ask my question in a simpler way. Imagine that I am 
inventing the oG language: An oG source file foo.og is translated to Go 
(file foo.go) by exchanging upper and lower cases letters, so the oG source 
file

 // file foo.og
PACKAGE PINK
IMPORT (
  "FMT"
)

FUNC pINKFLOYDS(S STRING) {
  FMT.pRINTF("IN pINKFLOYS S=%V\N", S)
}


is (trivially) translated to this Go file
// FILE FOO.OG
package pink
import (
  "fmt"
)

func Pinkfloyds(s string) {
  fmt.Printf("in Pinkfloyds s=%v\n", s)
}

and we are all able to code in Go the trivial Og to Go compiler (just 
translate uppercase to lowercase and vice-versa)

I think my question can be paraphrased as:

Write the Og compiler (compiled into command og) in Go, so that when running
og /tmp/pink/ /tmp/blue/
the following things are happening in turn:

   - every .og file in /tmp/pink/ directory, e.g. /tmp/pink/pink1.og 
   /tmp/pink/pink2.og is trivially translated to its .go file pink1.go & 
   pink2.go (that file can be in whatever directory is 

[go-nuts] debugging with delve

[Robert Solomon]

I am a newbie to Go.  I'm trying to figure out how to use delve, but I
think the documentation assumes I know more than I do.

I did the go get command, and there were no errors.  But when I try to
invoke it using either
$ dlv
$ delve

I get a "no command found.  did you mean ..." error.

I think I'm missing something very basic.  What am I missing?

thx
Rob Solomon

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

Re: [go-nuts] debugging with delve

[Matt Harden]

Add $GOHOME/bin to your $PATH.

On Sun, Apr 2, 2017 at 8:56 AM Robert Solomon  wrote:

> I am a newbie to Go.  I'm trying to figure out how to use delve, but I
> think the documentation assumes I know more than I do.
>
> I did the go get command, and there were no errors.  But when I try to
> invoke it using either
> $ dlv
> $ delve
>
> I get a "no command found.  did you mean ..." error.
>
> I think I'm missing something very basic.  What am I missing?
>
> thx
> Rob Solomon
>
> --
> 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.
>

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

Re: [go-nuts] dep: Roadmap for merging into the toolchain

[Peter Bourgon]

The dep project is in an alpha state; we'll leave alpha and enter a
versioned releases phase as soon as the manifest/lock file format
changes are in.

On Fri, Mar 31, 2017 at 2:32 AM, Kiyoshi Murata  wrote:
> I think Russ' feedback may imply dep needing to be versioned, as in the
> project itself publishing releases. Specially considering Peter Bourgon's
> lastest response, there's no way of users to know if dep is usable yet or
> not (roadmap is too abstract in that regard), and after that, what features
> made in. Is that a real concern or am I too off the mark here?
>
> On Tuesday, March 28, 2017 at 5:39:06 AM UTC-3, Peter Bourgon wrote:
>>
>> On Tue, Mar 28, 2017 at 3:14 AM, Russ Cox  wrote:
>> > On Mon, Mar 13, 2017 at 5:09 PM, Russ Cox  wrote:
>> >>
>> >> By far the most important things to do with dep right now are (1) build
>> >> something people can use and get benefit from today and eliminate
>> >> blockers
>> >> to adoption and (2) based on experience with that usage, learn what the
>> >> eventual design and go command integration should look like.
>> >
>> > I've been away and am not fully back yet, but I want to reemphasize
>> > these
>> > two lines, for everyone on this list and anyone else reading. I've heard
>> > a
>> > few people in various forums saying things like "I won't use dep until
>> > it's
>> > official".
>> >
>> > Please don't wait. Use it now. Make it possible for dep users to depend
>> > on
>> > specific versions of your packages: convert your packages to have
>> > manifest
>> > and lock files, and add version tags to your repos. Use dep for your own
>> > projects, to find out how well the approach works. Let us know.
>>
>> Agreed! But one important addendum: please wait until we've merged in
>> the manifest/lock file format changes[0][1] :) I'll post another
>> update to this thread when that's complete, as well as update dep's
>> README to remove the warnings. Thanks!
>>
>> [0] https://github.com/golang/dep/issues/119
>> [1] https://github.com/golang/dep/issues/168
>>
>>
>> > This is all critical. If you wait to try any of this until it's in the
>> > go
>> > command, then your feedback basically won't have any impact, because
>> > things
>> > will be so much harder to change at that point.
>> >
>> > (The flip side of this is that dep should freeze these basic details so
>> > that
>> > users aren't chasing a moving target. They don't need to be perfect. We
>> > know
>> > that JSON is not perfect, for example, but it's fine for this trial. The
>> > goal is to learn about the overall experience and semantics offered, not
>> > the
>> > file format.)
>> >
>> > Russ
>> >
>> > --
>> > 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.
>> > 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.

-- 
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: Best practice for Method Receivers

[st ov]

Could you explain how this is a race condition?
Running it in the playground appears to succeed, 
https://play.golang.org/p/zs6T361fc6




On Saturday, March 25, 2017 at 7:51:52 PM UTC-7, Dragos Harabor wrote:
>
> You may also run into subtle races when you mix pointer and value 
> receivers, as seen here:
> https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race
>
>
> On Friday, March 24, 2017 at 6:20:06 PM UTC-7, st ov wrote:
>>
>> Is it idiomatic to mix-&-match pointer and value method receivers for a 
>> given type? 
>> or in *general*, if a single method requires a pointer receiver than *all 
>> methods* should take a pointer, regardless if a value receiver is 
>> appropriate?
>>
>> For example, should Foo.SetVal also be a pointer receiver even though a 
>> value receiver would be acceptable?
>> https://play.golang.org/p/rd_6BLol8O
>>
>> type Foo struct{
>> ref []int
>> val int
>> }
>>
>> // would not set if method receiver is value receiver (foo Foo)
>> func (foo *Foo) SetRef(ref []int) {
>> foo.ref = ref
>> }
>> func (foo Foo) SetVal(val int) {
>> foo.val = val
>> }
>>
>> func main() {
>> foo := Foo{}
>> foo.SetRef([]int{1,2,3})
>> foo.SetVal(1)
>> 
>> fmt.Printf("%v",foo) // {[1 2 3] 0}
>> }
>>
>>
>>
>>

-- 
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: Best practice for Method Receivers

[Dragos Harabor]

You need to run it on your own machine with the -race flag, e.g.:
go run -race file.go

More info on the race detector:
https://golang.org/doc/articles/race_detector.html


On Sunday, April 2, 2017 at 2:57:59 PM UTC-7, st ov wrote:
>
> Could you explain how this is a race condition?
> Running it in the playground appears to succeed, 
> https://play.golang.org/p/zs6T361fc6
>
>
>
>
> On Saturday, March 25, 2017 at 7:51:52 PM UTC-7, Dragos Harabor wrote:
>>
>> You may also run into subtle races when you mix pointer and value 
>> receivers, as seen here:
>> https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race
>>
>>
>> On Friday, March 24, 2017 at 6:20:06 PM UTC-7, st ov wrote:
>>>
>>> Is it idiomatic to mix-&-match pointer and value method receivers for a 
>>> given type? 
>>> or in *general*, if a single method requires a pointer receiver than *all 
>>> methods* should take a pointer, regardless if a value receiver is 
>>> appropriate?
>>>
>>> For example, should Foo.SetVal also be a pointer receiver even though a 
>>> value receiver would be acceptable?
>>> https://play.golang.org/p/rd_6BLol8O
>>>
>>> type Foo struct{
>>> ref []int
>>> val int
>>> }
>>>
>>> // would not set if method receiver is value receiver (foo Foo)
>>> func (foo *Foo) SetRef(ref []int) {
>>> foo.ref = ref
>>> }
>>> func (foo Foo) SetVal(val int) {
>>> foo.val = val
>>> }
>>>
>>> func main() {
>>> foo := Foo{}
>>> foo.SetRef([]int{1,2,3})
>>> foo.SetVal(1)
>>> 
>>> fmt.Printf("%v",foo) // {[1 2 3] 0}
>>> }
>>>
>>>
>>>
>>>

-- 
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: How to abort the http ResponseWriter

[Song Liu]

Is there any other official way to cancel a ResponseWriter ?

Many thanks.

On Saturday, April 1, 2017 at 8:12:55 PM UTC+8, Song Liu wrote:
>
>
> I am implementing a file server, so http.ServerFile used to write back the 
> file content to remote client:
>
>
> func downloadFile(w http.ResponseWriter, r *http.Request, p 
> httprouter.Params) {
> ...
>
> http.ServeFile(w, r, filePath)
> }
>
>
> But sometimes the server want to abort the downloading, so what's the way 
> to abort the ResponseWriter ?
>
>
> Any information would be very appreciated, 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.
For more options, visit https://groups.google.com/d/optout.