Re: [go-nuts] where is GOROOT set?

2022-12-10 Thread Brian Candler
On Saturday, 10 December 2022 at 05:50:53 UTC pat2...@gmail.com wrote:

> thanks, and the playground is nice.
>
> I think this is saying that if I want a baz and bar executable (chmod +x)
> then I need the "package main" in separate folders/directories
>

Yes.  The approach I use (which I borrowed from some other project) is to 
have

cmd/baz/
cmd/bar/
bin/

directories, with cmd/{baz,bar}/ containing *.go files for each 
executable.  Then at the top level,

*go build -o bin ./...*
 
will make everything, and stick the binaries in the 'bin' directory.  The 
binaries will be named after their enclosing directories, i.e. "baz" and 
"bar".  Alternatively you can build them separately, e.g.

(cd cmd/baz; go build .)

You only need a single go.mod file at the top level.  If that declares the 
module as github.com/xxx/yyy, then people can build and install your 
binaries individually as, for example,
go install github.com/xxx/yyy/cmd/baz@latest

I'm not sure the official way to install *all* the binaries at once, but 
this seems to work:
go install github.com/xxx/yyy/...@latest

-- 
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/34e9e726-9ec6-4f56-95f7-75e4cf9af194n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-12-09 Thread pat2...@gmail.com
thanks, and the playground is nice.

I think this is saying that if I want a baz and bar executable (chmod +x)
then I need the "package main" in separate folders/directories

I don't think I'm close enough to understanding this stuff to focus on 
optimizing it to
the fewest possible go.mod files, but I'll keep this in mind if I can get 
to the point of
creating a few source files, driving and testing them without blood on my 
desk from banging my
head into it.

Thanks
Pat

p.s. all my code is in my github reposities, with the real github path in 
the code I've posted. 

-- 
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/df54ea53-bf97-4493-b4b9-509829cf1a1bn%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-12-09 Thread Brian Candler
Plus, you don't need to do a "go mod init" in each subdirectory.  The 
top-level directory names the module and the package within it; you can 
refer to packages in subdirectories using this module name with the 
subdirectory appended.

A typical layout would look like this:

(top level)
go mod init example.com/foo

[whatever.go]
package main
import "example.com/foo/bar"
import "example.com/foo/baz"


(subdirectory "bar")
[whatever.go]
package bar
import "example.com/foo/baz"  // if required
...

(subdirectory "baz")
[whatever.go]
package baz
import "example.com/foo/bar"  // if required
...

You can test all this in the playground: 
https://go.dev/play/p/-PR3oartg0t

On Friday, 9 December 2022 at 05:39:12 UTC Volker Dobler wrote:

> You cannot have multiple packages (in your case main and goprorename)
> in one folder. This has nothing to do with modules. You must but these
> three files into two different folders based on their package declaration.
>
> You might want to work through https://go.dev/doc/code
>
> 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/88465fba-8cfa-406c-84d8-1f7b4ccc5212n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-12-08 Thread Volker Dobler
You cannot have multiple packages (in your case main and goprorename)
in one folder. This has nothing to do with modules. You must but these
three files into two different folders based on their package declaration.

You might want to work through https://go.dev/doc/code

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/06762e81-1316-4bbd-8e47-e5a35d0c16d9n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-12-08 Thread pat2...@gmail.com
Thanks 
I've read the official tutorial and your create-module docs.
They help, but I am still having issues getting this to hang together.
I got the treesort example to work. 

Now I'm creating a new module, in a new subdirectory of my repositories
and I've done the go mod init

I have three go source files in the directory and the generated go.mod file
goprorename.go is what will eventually be a module/library of nice code.
goprorename_test.go is the test driver. Each of these two files are 
"package goprorename"
in the source.
main.go is a trivial file to run in the shell, creating an executable, 
probably named main.exe
that can accept shell arguments and call the nice code methods and 
functions.

I can't get the automatic compilation to work. i can't get testing to work. 
I can't get
the main/main.exe created. 

Here are the contents of the go.mod and the top lines of each of the three 
go source files.

It has to be someting trivial that I am doing wrong or missing.
Thanks
Pat

pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 go.mod
module github.com/pfarrell51/gows/goprorename

go 1.19
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 goprorename.go
// rename files created by a GoPro into a single, sensible
// ordering of files so that the order is obvious for easy processing
// by other utulities such as RaceRender
//
// goPro naming conventions: 
https://community.gopro.com/s/article/GoPro-Camera-File-Naming-Convention?language=en_US

package goprorename

import (
"fmt"
"io/fs"
"regexp"
"strings"
)

pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 
goprorename_test.go
// test driver for gopro rename utility
package goprorename

import (
"fstest"
"testing"
)

func TestProcessFile(t *testing.T) {

fsys := fstest.MapFS{
"file.go":{},
"subfolder/subfolder.go": {},
"subfolder2/another.go":  {},
"subfolder2/file.go": {},
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ head -n 15 main.go
// shell program to rename files created by a GoPro into a single, sensible
// ordering of files so that the order is obvious for easy processing
// by other utulities such as RaceRender
//
// goPro naming conventions: 
https://community.gopro.com/s/article/GoPro-Camera-File-Naming-Convention?language=en_US

package main

import (
"fmt"
"github.com/pfarrell51/gows/goprorename"
"os"
)


pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build .
found packages goprorename (goprorename.go) and main (main.go) in 
/home/pfarrell/whome/sandbox/gows/goprorename
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build goprorename
package goprorename is not in GOROOT (/usr/local/go/src/goprorename)
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build main
package main is not in GOROOT (/usr/local/go/src/main)
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build main.go
main.go:11:2: found packages goprorename (goprorename.go) and main 
(main.go) in /home/pfarrell/whome/sandbox/gows/goprorename


// these two compile cleanly when explicitly built.
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build goprorename.go
pfarrell@Alien15:~/whome/sandbox/gows/goprorename$ go build 
goprorename_test.go




>>

-- 
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/933d893e-8d42-466a-8664-85ac2d1bc7een%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-28 Thread thepud...@gmail.com
Hi Pat,

FWIW, I pulled together a TLDR on modules some time ago that I think hits 
upon each of the different issues you encountered in this thread. It also 
tries to summarize the core modules concepts, along with a bit of advice on 
how to stay on the "happy path" when starting out with Go modules. It is 
located here:

  https://stackoverflow.com/a/57314494/11210494

That might be worth a quick read, especially if you found anything puzzling 
so far.

It is likely also worthwhile to go through the official Go modules tutorial 
from the Go project:

  https://go.dev/doc/tutorial/create-module

Finally, looking over the thread, it seems you started by chasing how to 
set GOROOT, which makes sense given the main error message you first saw 
mentions GOROOT. 

GOROOT was a bit of a red herring, and I opened an issue suggesting that 
error message be modified to something more helpful:

  #56965 -- cmd/go: consider reducing use of the word 'GOROOT' in error 
messages
  https://github.com/golang/go/issues/56965
  
Feel free to comment there or here if you have any additional thoughts on 
what would have made your journey simpler.

Best regards,
thepudds

On Friday, November 25, 2022 at 10:48:40 PM UTC-5 pat2...@gmail.com wrote:

> Thanks
> That seems to be the solution
>

-- 
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/c3c5c0ea-4d01-4bbb-9aa8-4442abfd459bn%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-25 Thread pat2...@gmail.com
Thanks
That seems to be the solution

-- 
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/3075c58d-f0a8-4e23-b163-ce1f106bd080n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-24 Thread Brian Candler
Your error comes from the spurious import of "treesort" in 
treesort_test.go.  (You are already inside package treesort; there is 
nothing to import)

With this line:

$ go test .
# example.com/blah
treesort_test.go:11:2: package treesort is not in GOROOT 
(/usr/local/go/src/treesort)
FAILexample.com/blah [setup failed]
FAIL

Without this line: it works, once I've completed the code.

$ cat treesort_test.go
// Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
// License: https://creativecommons.org/licenses/by-nc-sa/4.0/

package treesort

import (
//"fmt"
"math/rand"
//"sort"
"testing"
)

func TestSort(t *testing.T) {
data := make([]int, 50)
for i := range data {
data[i] = rand.Int() % 50
}
}

$ go test .
ok  example.com/blah(cached)

On Thursday, 24 November 2022 at 19:09:18 UTC pat2...@gmail.com wrote:

> Sure 
>  
> cat treesort.go
>
> // Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
> // License: https://creativecommons.org/licenses/by-nc-sa/4.0/
>
> // See page 101.
>
> // Package treesort provides insertion sort using an unbalanced binary 
> tree.
> package treesort
>
> // !+
> type tree struct {
> value   int
> left, right *tree
> }
>
>
> cat treesort_test.go
>
> // Copyright © 2016 Alan A. A. Donovan & Brian W. Kernighan.
> // License: https://creativecommons.org/licenses/by-nc-sa/4.0/
>
> package treesort
>
> import (
> "fmt"
> "math/rand"
> "sort"
> "testing"
> "treesort"
> )
>
> func TestSort(t *testing.T) {
> data := make([]int, 50)
> for i := range data {
> data[i] = rand.Int() % 50
> }
>
>
>

-- 
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/2891c58a-54c5-4ba3-a44c-1605f7c0330en%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-24 Thread Brian Candler
On Wednesday, 23 November 2022 at 23:25:51 UTC pat2...@gmail.com wrote:

> I've separated my code into separate subdirectories, added a go.mod
> ran go mod tidy on each.
>
> I'm mostly back where I started, which a better source file tree
>
> I'm trying to test the "treesort" package from the "Donovan and Kernigan" 
> The Go programing language book.
>
> When I connect into the treesort subdirectory, you can see the files, but 
> I get a bad GOROOT error trying to do a "go test ."
>
> treesort$ ls
> go.mod  treesort.go  treesort_test.go
>
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ cat go.mod
> module github.com/pfarrell51/gows/treesort
>
> go 1.19
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ go test .
> # github.com/pfarrell51/gows/treesort
>
> treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program 
> Files\Go\src\treesort)
> FAILgithub.com/pfarrell51/gows/treesort [setup failed]
> FAIL
>
> How can I get past this?
>

Can you show the first 10 lines of your "treesort.go" and 
"treesort_test.go" files please?

I'm looking for the package lines and the import lines in particular.

-- 
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/47000957-873d-4124-a09e-1521dc8ae6dfn%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread Kurtis Rader
Show us the output of `which go`. I'm not convinced you're using a native
Linux Go compiler.

On Wed, Nov 23, 2022 at 5:31 PM pat2...@gmail.com 
wrote:

> Just in case my use of the "windows installer" for go and then using
> WSL/bash
>
>> was confusing assorted magic env variables, I uninstalled/deleted the
> Windows installed version
> then I downloaded the "linux" version, and did the usual "sudo tar "
> install
>
> Made no difference
> Get the same error message
>
> $ cat go.mod
> module github.com/pfarrell51/gows/treesort
>
> go 1.19
>
>
> $ go test .
> # github.com/pfarrell51/gows/treesort
> treesort_test.go:11:2: package treesort is not in GOROOT
> (/usr/local/go/src/treesort)
> FAILgithub.com/pfarrell51/gows/treesort [setup failed]
> FAIL
>
> --
> 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/337a21ff-6c06-440d-9aa9-89aa4a1d071an%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD96YsSy62C%2BtQZ6NQCv6uvAt56b5%2Bb%3Dn0D5qwYo2EJyww%40mail.gmail.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread Kurtis Rader
In your reply to the request for `go env` output you say "For all of the
above I am using WSL (bash under Windows 11)". It looks like you're using
the native Windows Go toolchain from WSL. I would not expect that to work
and that is likely the reason you're having problems. You should install Go
for Linux in WSL and use that. Note that "bash under Windows" isn't an
accurate description of WSL (although, it is a widely used one). WSL is
really a way to run Linux side-by-side with Windows in a manner akin to
what you would get with a third-party tool like VMware and with sharing of
filesystems. Running a native Windows program from WSL might work but you
cannot assume that is true.

On Wed, Nov 23, 2022 at 4:40 PM pat2...@gmail.com 
wrote:

> On Wednesday, November 23, 2022 at 7:00:35 PM UTC-5 kra...XXX wrote:
>
>> On Windows Go is normally installed to C:\Program Files\Go. You should
>> not put your source code inside that directory. Put the source for your
>> projects somewhere else such as %HOME%/go.
>>
>
> My source files are not under "C:\Program Files\Go"
>
> They are under a separate directory:
> /home/pfarrell/whome/sandbox/gows/treesort
>
> The error message contains an invented path that does not exist
>
> $ go test .
> # github.com/pfarrell51/gows/treesort
> treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program
> Files\Go\src\treesort)
> FAILgithub.com/pfarrell51/gows/treesort [setup failed]
>
>> --
> 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/e8814b02-d072-4272-a12b-4509d353666cn%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9WqiNyEga-oJO1LKBeSq6nmEJf-scxxy77hmakgaXXJA%40mail.gmail.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread pat2...@gmail.com
Just in case my use of the "windows installer" for go and then using 
WSL/bash

> was confusing assorted magic env variables, I uninstalled/deleted the 
Windows installed version
then I downloaded the "linux" version, and did the usual "sudo tar " install

Made no difference
Get the same error message 

$ cat go.mod
module github.com/pfarrell51/gows/treesort

go 1.19


$ go test .
# github.com/pfarrell51/gows/treesort
treesort_test.go:11:2: package treesort is not in GOROOT 
(/usr/local/go/src/treesort)
FAILgithub.com/pfarrell51/gows/treesort [setup failed]
FAIL

-- 
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/337a21ff-6c06-440d-9aa9-89aa4a1d071an%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread pat2...@gmail.com
On Wednesday, November 23, 2022 at 7:00:35 PM UTC-5 kra...XXX wrote:

> On Windows Go is normally installed to C:\Program Files\Go. You should not 
> put your source code inside that directory. Put the source for your 
> projects somewhere else such as %HOME%/go.
>

My source files are not under "C:\Program Files\Go"

They are under a separate directory:
/home/pfarrell/whome/sandbox/gows/treesort

The error message contains an invented path that does not exist

$ go test .
# github.com/pfarrell51/gows/treesort
treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program 
Files\Go\src\treesort)
FAILgithub.com/pfarrell51/gows/treesort [setup failed]

>

-- 
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/e8814b02-d072-4272-a12b-4509d353666cn%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread pat2...@gmail.com
On Wednesday, November 23, 2022 at 6:31:51 PM UTC-5 se... wrote:

> output of `go env` please
>


I am using WSL (bash under Windows 11)

Shell env:
 env
HOSTTYPE=x86_64
LESSCLOSE=/usr/bin/lesspipe %s %s
LANG=C.UTF-8
WSL_DISTRO_NAME=Ubuntu
USER=pfarrell
PWD=/home/pfarrell/whome/sandbox/gows/treesort
HOME=/home/pfarrell
_=/usr/bin/env
pfarrell@Alien15:~/whome/sandbox/gows/treesort$


treesort$ go env
treesort$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\pfarrell\AppData\Local\go-build
set GOENV=C:\Users\pfarrell\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\pfarrell\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\pfarrell\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19.2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\pfarrell\sandbox\gows\treesort\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments 
-Wl,--no-gc-sections -fmessage-length=0 
-fdebug-prefix-map=C:\Users\pfarrell\AppData\Local\Temp\go-build2617285960=/tmp/go-build
 
-gno-record-gcc-switches
pfarrell@Alien15:~/whome/sandbox/gows/treesort$

[its unclear how the "GOPATH" was set, as it is not set in the shell env.]


Please note, the current pwd is
$ pwd
/home/pfarrell/whome/sandbox/gows/treesort

There is no such directory as the error message is reporting:
" (C:\Program Files\Go\src\treesort)"

There is a file, where the go installation process put a bunch of source 
files, so there is
" (C:\Program Files\Go\src)"

/mnt/c/Program Files/Go/src$ ls
Make.dist   bufio  cmddebug go  internal   mime 
  reflect   strconv   time
README.vendor   buildall.bash  cmp.bash   embed go.mod  io net 
   regexpstrings   unicode
all.bashbuiltincompress   encoding  go.sum  logos   
  run.bash  sync  unsafe
all.bat bytes  container  errorshashmake.bash  path 
  run.bat   syscall   vendor
all.rc  clean.bash contextexpvarhtmlmake.bat   
plugin run.rctestdata
archive clean.bat  crypto flag  image   make.rc   
 race.bash  runtime   testing
bootstrap.bash  clean.rc   database   fmt   index   math   
race.bat   sort  text

For all of the above I am using WSL (bash under Windows 11)
Just for fun, I tried Windows Power Shell (which I never use)

'C:\Program Files\go\bin\go.exe' test .
# github.com/pfarrell51/gows/treesort
treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program 
Files\go\src\treesort)
FAILgithub.com/pfarrell51/gows/treesort [setup failed]
FAIL

Thanks
Pat



















 


 

-- 
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/43b30510-6d78-4874-aec0-eeb2a92651e9n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread Kurtis Rader
On Windows Go is normally installed to C:\Program Files\Go. You should not
put your source code inside that directory. Put the source for your
projects somewhere else such as %HOME%/go.

On Wed, Nov 23, 2022 at 3:26 PM pat2...@gmail.com 
wrote:

> I've separated my code into separate subdirectories, added a go.mod
> ran go mod tidy on each.
>
> I'm mostly back where I started, which a better source file tree
>
> I'm trying to test the "treesort" package from the "Donovan and Kernigan"
> The Go programing language book.
>
> When I connect into the treesort subdirectory, you can see the files, but
> I get a bad GOROOT error trying to do a "go test ."
>
> treesort$ ls
> go.mod  treesort.go  treesort_test.go
>
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ cat go.mod
> module github.com/pfarrell51/gows/treesort
>
> go 1.19
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ go test .
> # github.com/pfarrell51/gows/treesort
> treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program
> Files\Go\src\treesort)
> FAILgithub.com/pfarrell51/gows/treesort [setup failed]
> FAIL
>
> How can I get past this?
> Thanks
> Pat
>
> --
> 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/4b365c67-6f3d-4edc-97d5-dbe505604818n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9U5vGq7O%3DZdf_t8BugwnJQwPud2jWzYGw4q02dKZmU5A%40mail.gmail.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread 'Sean Liao' via golang-nuts
output of `go env` please

- sean


On Wed, Nov 23, 2022 at 11:25 PM pat2...@gmail.com 
wrote:

> I've separated my code into separate subdirectories, added a go.mod
> ran go mod tidy on each.
>
> I'm mostly back where I started, which a better source file tree
>
> I'm trying to test the "treesort" package from the "Donovan and Kernigan"
> The Go programing language book.
>
> When I connect into the treesort subdirectory, you can see the files, but
> I get a bad GOROOT error trying to do a "go test ."
>
> treesort$ ls
> go.mod  treesort.go  treesort_test.go
>
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ cat go.mod
> module github.com/pfarrell51/gows/treesort
>
> go 1.19
>
> pfarrell@Alien15:~/whome/sandbox/gows/treesort$ go test .
> # github.com/pfarrell51/gows/treesort
> treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program
> Files\Go\src\treesort)
> FAILgithub.com/pfarrell51/gows/treesort [setup failed]
> FAIL
>
> How can I get past this?
> Thanks
> Pat
>
> --
> 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/4b365c67-6f3d-4edc-97d5-dbe505604818n%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/CAGabyPq5pSoL6w1Mbgj2A7ip7OuL2q1_hok7DBfcFK77fpxp-Q%40mail.gmail.com.


Re: [go-nuts] where is GOROOT set?

2022-11-23 Thread pat2...@gmail.com
I've separated my code into separate subdirectories, added a go.mod
ran go mod tidy on each.

I'm mostly back where I started, which a better source file tree

I'm trying to test the "treesort" package from the "Donovan and Kernigan" 
The Go programing language book.

When I connect into the treesort subdirectory, you can see the files, but I 
get a bad GOROOT error trying to do a "go test ."

treesort$ ls
go.mod  treesort.go  treesort_test.go


pfarrell@Alien15:~/whome/sandbox/gows/treesort$ cat go.mod
module github.com/pfarrell51/gows/treesort

go 1.19

pfarrell@Alien15:~/whome/sandbox/gows/treesort$ go test .
# github.com/pfarrell51/gows/treesort
treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program 
Files\Go\src\treesort)
FAILgithub.com/pfarrell51/gows/treesort [setup failed]
FAIL

How can I get past this?
Thanks
Pat

-- 
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/4b365c67-6f3d-4edc-97d5-dbe505604818n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-21 Thread Brian Candler
On Monday, 21 November 2022 at 04:11:26 UTC pat2...@gmail.com wrote:

>
> Incidentally, there is no need to have github.com in the directory path 
>> on your local filesystem.  You could just use
>> ~/projects/cmd
>>
>
> Doesn't this contradict putting the github path in the name for easy 
> automatic use?
> Or am I confusing two issues?
>
>
You are confusing two issues, although this probably comes from your 
experience with go before GOMODULES, where you did have an 
automatically-created hierarchy under $GOPATH/src.  I came to go just as 
the transition was taking place.

There are two separate concepts now:

(1) The *name* of your module.  This conventionally looks like 
github.com/pfarrell51/cmd to allow automatic fetching from github (but 
doesn't have to).

(2) The *directory* on your local filesystem where your code lives.  This 
can be anywhere and does not have to look anything like your module name.  
This is because the "go.mod" file provides the binding between the module 
name and filesystem location.

- if the current directory contains go.mod, then go.mod names the package 
in this directory
- if the current directory doesn't contain go.mod, then go walks up the 
filesystem to find one.  Then the name of the package in the current 
directory is the name of the module in go.mod, concatenated with the 
subdirectory path needed to get from go.mod's directory to this one.

That is: if ~/projects/misc contains a go.mod with name example.com/test, 
then ~/project/misc/foo has name example.com/test/foo implicitly (as long 
as it doesn't have its own go.mod file).

 
>
>> Note that import "github.com/pfarrell51/cmd" doesn't mean "fetch this 
>> code from github".  It just refers to the module's name.  By walking up the 
>> parent directories and finding go.mod, Go realises that the named module 
>> you are referring to is already on your filesystem as part of your project, 
>> and uses that directly.  This is why it works to use random module names 
>> like example.com/test
>>
>
> I'm not following this, I thought that was exactly why I put in the "
> github.com/pfarrell51/< modulename>"
> in the source directory structure, and therefor in the github 
> https://github.com/pfarrell51/gows repository
> so if someone wanted to use my PID code or my quaternion code, it would be 
> easy and automatic
>
>
For somebody on a remote system, yes.

On your own system, let's say you have the following tree:

~/projects/cmd  # contains go.mod with name github.com/pfarrell51/cmd
~/projects/cmd/foo
~/projects/cmd/bar

In the "foo" subdirectory, there is some code which says

import "github.com/pfarrell51/cmd/bar"

When you compile this code, go finds the go.mod file *in your own 
filesystem* (in the enclosing directory).  It knows that ~/projects/cmd is 
github.com/pfarrell51/cmd.  Therefore, github.com/pfarrell51/cmd/bar can be 
found at ~/projects/cmd/bar (as long as that subdirectory doesn't have its 
own go.mod file).

Hence it doesn't go off to github to fetch github.com/pfarrell51/cmd/bar - 
which would be very confusing, since this is a package inside the module 
you're actively developing, and may not even have been published to github 
at all yet.  It uses the local copy.

Now suppose you've finished it, and you push it to github.  A different 
person writes some code with

import "github.com/pfarrell51/cmd/bar"

For their own code, they need to have their own go.mod file with their own 
module name.  The system can see easily that the module they're writing is 
not the same as the one they're importing.  In this case, "go mod tidy" 
will go off to github and fetch the code, i.e. *your* code which *their* 
code depends on, and drop it into $GOMODCACHE

I hope this makes a bit more sense!  There is a nice series of blog 
articles starting at https://go.dev/blog/using-go-modules, although this 
assumes you know the old behaviour whereas really this is historic now.

Regards,

Brian.

-- 
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/61ce3bdd-1028-4dd1-8af5-b0552b498e7fn%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-20 Thread pat2...@gmail.com
Thanks again

Bit of background, I've been playing with go on and off for five or six 
years. I have decades of experience in 
various systems programming languages, including things like TOPS-10 macro, 
c, bliss, etc. Go is very
attractive to my systems-internals side. 
About five years ago I started writing some go programs that were typical 
shell programs that
two decades ago I would have written in perl. Thus the "cmd" directory 
since in the windows world at the time,
you ran in the 'cmd shell'

I've recently got the bug again to write some go.
Over the years, go has changed, and example programs on the web have 
changed.
So what I am copying from has various vintages and has code from many 
sources, some of which may be very obsolete.

On Saturday, November 19, 2022 at 3:15:08 AM UTC-5 Brian Candler wrote:

> But you don't need to split into multiple subdirectories at this point: 
> only multiple files in the same directory.  (Unless you're talking about 
> separate executables, in which case, yes they need to be in separate 
> subdirectories).
>

Yes, I was specifically talking about creating separate executables.
So one subdirectory for each separate executable it shall be.

  

> Do I really need to have the source code deeply burried in names that tie 
>> it all to my github repository?
>>
> I'm not sure what you mean by that.  All the source files in the same 
> package (in the same directory) don't need to import each other at all, so 
> they do not reference each other by module name.
>

I am in the habit of sharing all of my code, with github being the sharing 
technique of choice over the past decade or so.


 

> The module name is used when you need to import code from somewhere else.  
> If you choose a module name that links to your github repository, then 
> other people will be able to import your module using that name, and the 
> code will be fetched and built automatically.
>

That is what I want to do. I want folks to be able to use my code if they 
want.
But the naming of the subdirectories with the full path to my github 
reposities is fairly ugly and cumbersome.
 


  

> I'm using
>>~/sandbox/gows/src/github.com/pfarrell51/cmd 
>> because "gows" is "go work space" with src code
>>
>
> Be careful with your terminology here: there is a specific feature called "go 
> workspaces ", but this has only 
> been recently added and is an advanced topic (for working on very large 
> projects) and you should ignore it for now.
>

Somewhere along the line, some example years ago talked about a go 
workspace, so I invented the gows subdirectory.


 

> Incidentally, there is no need to have github.com in the directory path 
> on your local filesystem.  You could just use
> ~/projects/cmd
>

Doesn't this contradict putting the github path in the name for easy 
automatic use?
Or am I confusing two issues?

If the "foo" and "bar" executables are completely independent and don't 
> share any code, then I would publish them as separate repos, each with 
> their own go.mod.
>

So far, they have all been completely independent, but that is mostly 
because in go, I'm a rookie and nothing I've written is very substantial.
 

> Note that import "github.com/pfarrell51/cmd" doesn't mean "fetch this 
> code from github".  It just refers to the module's name.  By walking up the 
> parent directories and finding go.mod, Go realises that the named module 
> you are referring to is already on your filesystem as part of your project, 
> and uses that directly.  This is why it works to use random module names 
> like example.com/test
>

I'm not following this, I thought that was exactly why I put in the "
github.com/pfarrell51/< modulename>"
in the source directory structure, and therefor in the github 
https://github.com/pfarrell51/gows repository
so if someone wanted to use my PID code or my quaternion code, it would be 
easy and automatic

Thanks
Pat

-- 
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/dd7a4e05-28a0-4264-b6db-f689a6684859n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-19 Thread Brian Candler
On Saturday, 19 November 2022 at 02:50:18 UTC pat2...@gmail.com wrote:

> On Friday, November 18, 2022 at 1:10:40 PM UTC-5 Brian Candler wrote:
>
>> You still should have a go.mod.  Even if you don't intend to publish your 
>> code anywhere, you give it a module name - anything will do as long as it 
>> meets the syntax requirements.
>>
>
> OK, I can have a go.mod
> But don''t I need to have a "package main" in order to get an executable?
>

Correct.  Your .go source file(s), which together build a single 
executable, will all have "package main" as the first line, and all sit in 
the same directory.

Starting point, with a single file:

mkdir hello
cd hello
go mod init example.com/hello# this creates "go.mod"
vi hello.go   # create your program here
go run .

where hello.go contains

package main
import "fmt"
func main() {
fmt.Println("Hello, world!")
}

You could then split this into two files:

-- hello.go --
package main
func main() {
sayHello()
}

-- speaker.go --
package main
import "fmt"
func sayHello() {
fmt.Println("Hello, world!")
}

In general, all source files in the same directory are part of the same 
package, and must have the same 'package' declaration. The exception is if 
you choose to put your test functions in a different package (if you want 
them only to be able to access the public API of your package)

You can have multiple .go source files, in the same directory, all part of 
the same package.  Functions in each file can use functions and data from 
any other file, without having to refer to them explicitly.

Think of "a directory of files" as a single compilation unit.  It's pretty 
much the same as having one big source file, except that each individual 
source file still has to have its own 'import' statements.

 

>
> If you need to split your code into other packages, you can put those in 
>> subdirectories.  Those don't need their own go.mod files.  The path for 
>> each package is the path from the outer go.mod file, concatenated with the 
>> subdirectory.
>>
>
> Sure, once there is more than 25 lines of source code, subdirectories make 
> sense.
>

But you don't need to split into multiple subdirectories at this point: 
only multiple files in the same directory.  (Unless you're talking about 
separate executables, in which case, yes they need to be in separate 
subdirectories).


 

>
> Do I really need to have the source code deeply burried in names that tie 
> it all to my github repository?
>

I'm not sure what you mean by that.  All the source files in the same 
package (in the same directory) don't need to import each other at all, so 
they do not reference each other by module name.

The module name is used when you need to import code from somewhere else.  
If you choose a module name that links to your github repository, then 
other people will be able to import your module using that name, and the 
code will be fetched and built automatically.

 

> I'm using
>~/sandbox/gows/src/github.com/pfarrell51/cmd
>  
> because "gows" is "go work space" with src code
>

Be careful with your terminology here: there is a specific feature called "go 
workspaces ", but this has only 
been recently added and is an advanced topic (for working on very large 
projects) and you should ignore it for now.

If you just mean "this is where I put my source files", then that's fine; 
but all the files in one directory must be part of the same package, and 
thus part of the same application (i.e. you build them all as one 
executable).

Incidentally, there is no need to have github.com in the directory path on 
your local filesystem.  You could just use

~/projects/cmd

What if you are building multiple executables?  You put them into separate 
subdirectories.  If you're treating this all as one module:

~/projects/cmd   contains  go.mod (and nothing else)
~/projects/cmd/foo  contains *.go files, all for package main, which build 
the "foo" executable
~/projects/cmd/bar  contains *.go files, all for package main, which build 
the "bar" executable

You can then if you wish publish this whole lot in a single repo as 
github.com/pfarrell51/cmd - or not, as you choose.  If not, then the name 
that you choose for your module doesn't matter.

This repo can also contain library code which is shared between these 
executables - this would be in separate packages, and would have to be 
explicitly imported by the executables.

Option 1: the top-level ~/projects/cmd can contain *.go files.  These might 
all have "package cmd" and can be imported using your bare module path, 
e.g. github.com/pfarrell51/cmd

Option 2: you can put library code in subdirectories too, e.g. 
~/projects/cmd/utils/ can contain *.go files, with "package utils", and are 
imported using github.com/pfarrell51/cmd/utils.  There is a special 
subdirectory "internal" which can be used for code which is shared between 
your own executables but you *don't* want to be avai

Re: [go-nuts] where is GOROOT set?

2022-11-18 Thread pat2...@gmail.com
thanks


On Friday, November 18, 2022 at 1:10:40 PM UTC-5 Brian Candler wrote:

> You still should have a go.mod.  Even if you don't intend to publish your 
> code anywhere, you give it a module name - anything will do as long as it 
> meets the syntax requirements.
>

OK, I can have a go.mod
But don''t I need to have a "package main" in order to get an executable?

If you need to split your code into other packages, you can put those in 
> subdirectories.  Those don't need their own go.mod files.  The path for 
> each package is the path from the outer go.mod file, concatenated with the 
> subdirectory.
>

Sure, once there is more than 25 lines of source code, subdirectories make 
sense.

Do I really need to have the source code deeply burried in names that tie 
it all to my github repository?
I'm using
   ~/sandbox/gows/src/github.com/pfarrell51/cmd
 
because "gows" is "go work space" with src code
and github/pfarrell51/cmd
is where I've kept all my shell/cmd program source.

Thanks
Pat

-- 
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/c2e66b9f-29db-4a70-acbc-416461beee1en%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-18 Thread Brian Candler
> They are just simple go programs that work like perl or python programs, 
designed to take work with pipes

You still should have a go.mod.  Even if you don't intend to publish your 
code anywhere, you give it a module name - anything will do as long as it 
meets the syntax requirements.
See example 
here: https://groups.google.com/g/golang-nuts/c/SUWXeLjuWY0/m/fg9nhD47DwAJ

Then you need "go test ." not "go test" (notice the dot)

> There are really no need for packages or modules for these programs.

These days, anything other than a trivial hello-world type program should 
have a go.mod.  As soon as you start importing any third party libraries 
you most definitely need it.

You will always have a package - at least package "main".

If you need to split your code into other packages, you can put those in 
subdirectories.  Those don't need their own go.mod files.  The path for 
each package is the path from the outer go.mod file, concatenated with the 
subdirectory.

On Friday, 18 November 2022 at 14:18:50 UTC pat2...@gmail.com wrote:

> OK, all the source files are in the same directory
> I did the go mod
> it didn't work as you typed, but I got it to work
>
> I'm pretty sure I don't understand packages and modules.
> I really an not using any of that, I just have a half dozen go files some 
> with main() and
> some with tests.
>
> I am now getting a different error message:
> $ go test
> found packages main (csvtsd.go) and quaternion (quaternion.go) in 
> C:\Users\pfarrell\sandbox\gows\src\github.com\pfarrell51\cmd
> pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$
>
> after doing this:
>
>
> $ go mod init
> go: cannot determine module path for source directory 
> C:\Users\pfarrell\sandbox\gows (outside GOPATH, module path must be 
> specified)
>
> Example usage:
> 'go mod init example.com/m' to initialize a v0 or v1 module
> 'go mod init example.com/m/v2' to initialize a v2 module
>
> Run 'go help mod init' for more information.
>
> $ go mod init src/github.com/pfarrell51/cmd/
> go: malformed module path "src/github.com/pfarrell51/cmd/": trailing slash
>
> $ go mod init src/github.com/pfarrell51/cmd
> go: creating new go.mod: module src/github.com/pfarrell51/cmd
> go: to add module requirements and sums:
> go mod tidy
> pfarrell@Alien15:~/whome/sandbox/gows$ go mod tidy
>
>
> $ go test
> found packages main (csvtsd.go) and quaternion (quaternion.go) in 
> C:\Users\pfarrell\sandbox\gows\src\github.com\pfarrell51\cmd
>
>
> It seems to be missing two test.go files in the directory:
> $ ls *test.go
> csvtsd_test.go  goprorename_test.go  quaternion_test.go  treesort_test.go
>
> There are really no need for packages or modules for these programs.
> They are just simple go programs that work like perl or python programs, 
> designed to take work with pipes
> Some have package names because the source I pulled from random places had 
> a package line.
>
>
>

-- 
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/b070d88a-4085-4fea-9d5b-4ba5d6422079n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-18 Thread Ian Lance Taylor
On Fri, Nov 18, 2022 at 6:19 AM pat2...@gmail.com  wrote:
>
> There are really no need for packages or modules for these programs.
> They are just simple go programs that work like perl or python programs, 
> designed to take work with pipes
> Some have package names because the source I pulled from random places had a 
> package line.

It is a little complicated to set up initially.  You do have to run
"go mod init PACKAGEPATH".  You do have to put different packages in
different directories.  We believe that although it is a little harder
to get started than some scripting languages, it pays off quickly in
the ease and security of importing and using other people's packages.

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/CAOyqgcV6%2BcP26bDoOK%2BCHLE5eJ0eoknP4iVQ-2JagNt-RW5y2g%40mail.gmail.com.


Re: [go-nuts] where is GOROOT set?

2022-11-18 Thread pat2...@gmail.com
OK, all the source files are in the same directory
I did the go mod
it didn't work as you typed, but I got it to work

I'm pretty sure I don't understand packages and modules.
I really an not using any of that, I just have a half dozen go files some 
with main() and
some with tests.

I am now getting a different error message:
$ go test
found packages main (csvtsd.go) and quaternion (quaternion.go) in 
C:\Users\pfarrell\sandbox\gows\src\github.com\pfarrell51\cmd
pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$

after doing this:


$ go mod init
go: cannot determine module path for source directory 
C:\Users\pfarrell\sandbox\gows (outside GOPATH, module path must be 
specified)

Example usage:
'go mod init example.com/m' to initialize a v0 or v1 module
'go mod init example.com/m/v2' to initialize a v2 module

Run 'go help mod init' for more information.

$ go mod init src/github.com/pfarrell51/cmd/
go: malformed module path "src/github.com/pfarrell51/cmd/": trailing slash

$ go mod init src/github.com/pfarrell51/cmd
go: creating new go.mod: module src/github.com/pfarrell51/cmd
go: to add module requirements and sums:
go mod tidy
pfarrell@Alien15:~/whome/sandbox/gows$ go mod tidy


$ go test
found packages main (csvtsd.go) and quaternion (quaternion.go) in 
C:\Users\pfarrell\sandbox\gows\src\github.com\pfarrell51\cmd


It seems to be missing two test.go files in the directory:
$ ls *test.go
csvtsd_test.go  goprorename_test.go  quaternion_test.go  treesort_test.go

There are really no need for packages or modules for these programs.
They are just simple go programs that work like perl or python programs, 
designed to take work with pipes
Some have package names because the source I pulled from random places had 
a package line.


-- 
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/28c6c748-9ec6-42e1-b211-d9115b62f221n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-17 Thread 'Dan Kortschak' via golang-nuts
On Thu, 2022-11-17 at 21:20 -0800, pat2...@gmail.com wrote:
> pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$
> go test treesort_test.go

This is not how go test should be invoked. You just need to do go test
in the directory that you package lives in.

See https://pkg.go.dev/cmd/go#hdr-Test_packages

-- 
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/b90053253a8db89fd84e5bedc477fe306d361380.camel%40kortschak.io.


Re: [go-nuts] where is GOROOT set?

2022-11-17 Thread pat2...@gmail.com
Here I clear it, same result:

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ export 
GOROOT=
pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ 
printenv GOROOT

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ go 
test treesort_test.go
# command-line-arguments
treesort_test.go:11:2: package treesort is not in GOROOT (C:\Program 
Files\Go\src\treesort)
FAILcommand-line-arguments [setup failed]
FAIL

Interesting: even though I cleared it to bash, it still shows up as being 
set in go

pfarrell@Alien15:~/whome/sandbox/gows/src/github.com/pfarrell51/cmd$ go env
set GO111MODULE=
set GOENV=C:\Users\pfarrell\AppData\Roaming\go\env
set GOPATH=C:\Users\pfarrell\go
set GOROOT=C:\Program Files\Go

-- 
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/3731200a-4cca-496c-b715-c06980679917n%40googlegroups.com.


Re: [go-nuts] where is GOROOT set?

2022-11-17 Thread Ian Lance Taylor
On Thu, Nov 17, 2022 at 8:59 PM pat2...@gmail.com  wrote:
>
> I'm missing something fundamental.
> I have set GOROOT to my current directory, which contains my go source files
> but I can't test a trivial program

In general you should never set GOROOT.  It's a special purpose hook
that is almost never needed.

What happens if you don't set it in the environment?

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