Re: [go-nuts] package is not in GOROOT

['Carla Pfaff' via golang-nuts]

On Thursday, 8 April 2021 at 02:11:50 UTC+2 rob wrote:

> Yes, you are absolutely correct that I've been struggling w/ modules. 
>
> Would it be a bad idea to use my ~go/src as a module? 
>
>   cd ~/go/src 
>
>   go mod init src 
>
>   go mod tidy --> do I need this? 
>
> And then I would have to edit my import statements slightly to include 
> the module reference. 
>
> --rob solomon 
>

That's basically what I suggested to you in my response. Only, instead of 
 "~/go/src" I called it "rob".

-- 
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/405db51e-f98a-48a5-9369-42b0f973dbacn%40googlegroups.com.

Re: [go-nuts] Modules... why it has to be so painfull?

[Justin Israel]

On Thursday, April 8, 2021 at 12:14:40 PM UTC+12 Slawomir Pryczek wrote:

> Thanks for all replies. Actually the docs are good (imo) just these  
> solutions proposed in docs are a horror.
>
> Inside root folder of the module... so im unable to share packages between 
> projects and code structure gets horrible, because now instead of nicely 
> organized 2 levels of nesting i have 3 levels and i need to repeat name of 
> the project 5 times inside every of 25 different root packages. Maybe for 
> small  apps. If i'm having eg. slab allocator used by both webserver and 
> k-v storage it'd be good to put it outside and not having half of the 
> modules in other apps imported from webserver and other half from k-v 
> storage. It introduces unneeded complexity if package pretends to have 
> something in common with something which is totally unrelated just because 
> it's easier to put it in there. Next i'll have to do v2 of webserver when 
> API of some of packages will change, so the version number won't reflect 
> version number of my app... but changes to some single package in it.
>
> Putting main app dir/files as a parent of general purpose packages is a 
> bad idea. Having tax app to be a parent of decimals package is like having 
> a 3d graph library to be a parent of network I/O package. There is no 
> relation so it should be separated for readability.
>
> >Have you tried go mod edit -replace github.com/foo/bar=/path/to/local/bar 
> ?
> I'll have to do hundreds of such edits and then re-edit it each time 
> anything changes (package rename, moving files, etc.)
>
> My point is why this module approach broken the ability to organize code 
> conviniently and logically... If we're in /src/foo and there is /src/bar 
> and we do import "bar" in foo... it should just (what a surprise) import 
> the local bar :D And another issue with this approach is that... should we 
> put this abomination inside git? So really, everyone who downloads my code 
> will have to waste 4 hours of his life replacing imports or he'll be forced 
> to do edits inside C:\Users\slawomir\go or maybe he'll edit in 
> F:\users\michael\my\nice\go\path and put it in repo so i'll have to change 
> it back :D
>
> I know it's easier said than done but we have all this nice things like 
> goroutines, GC, channels, peemption... and everything is so simple. Just to 
> manually babysit package manager when previous model was working? Even 
> having the user go to command line and issue module init for something 
> without remote imports is a step backwards, because it's a waste of time, 
> added complexity and totally unneeded.
>
> Having like tens of pages of "instructions" and blog posts telling users 
> how to configure package manager just to run 10 lines of code if we want to 
> organize it well is a step forward? With GOPATH you did one simple thing 
> and it was working. Just once not 1000 times over and over, for each 
> package or after anything in your dev enviroment changed. So not sure why 
> everyone should be forced to migrate to this cumbersome model when we have 
> nicely organized, self containted projects and the only issue is versioning 
> for the PART of projects which are actually ... libraries, not applications.
>
> >One solution is apparently to use a module like a giant mono repo, aka 
> gopath
> Still it requires for this replace and keeping absolute paths everywhere. 
> It's not even possible to put your project on github this way because it 
> won't compile without configuring everything. That's a huge regression 
> because you'll have to copy-paste all shared code inside each individual 
> app folder if you don't want to publish 30 packages as separate modules or 
> put unrelated things together. Each solution is sub-optimal because 
> separation can't just be done right in sane amount of time in this model 
> because PM isn't able to conviniently handle local packages nor 
> initialization nor changes in the packages...
>
> My point is, that it's so inconvinient that you'll organize your code 
> badly just to save time... GOPATH is much better approach for bigger apps 
> and it shouldn't be made obsolete. At least not if the only solution is 
> putting things where they don't belong or setting up proxies to pretend 
> local files are remote and then re-running some command line tools each 
> time you add a line in one of these...
>

My take on this is that you appear to be aggressively ranting about modules 
with assertions about how it does or does not function, before actually 
discovering what modules truly do or do not do. People are more likely 
inclined to be helpful if you just present your situation, what you tried, 
and what you expect. But leave out the bits where it is assumed to be a 
broken implementation that can not do what you want, that it is poorly 
conceived, and how frustrated and angry those assumptions makes you feel. 
Your frustrations are valid, but they are likely based on incomplete or 

Re: [go-nuts] Strange behaviour with loops #45192, #45175

[Sebastien Rosset]

That's a great idea. Thank you! I am doing that right now.

On Wed, Apr 7, 2021 at 5:05 PM 'Keith Randall' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> If you look at CL 304251, there's one place where we added "return false".
> Put a panic just before that line (in 1.15.11 or 1.16.3), rebuild the
> compiler, then rebuild your program and see if your program triggers that
> panic.
>
>
> On Wednesday, April 7, 2021 at 2:37:53 PM UTC-7 Ian Lance Taylor wrote:
>
>> On Wed, Apr 7, 2021 at 1:47 PM sro...@gmail.com 
>> wrote:
>> >
>> > Is there a way to analyze a go program and determine whether it is
>> susceptible to bug https://github.com/golang/go/issues/45175?
>> > While the obvious solution is to upgrade to 1.15.11 or 1.16.3, it would
>> still be useful to analyze existing programs, either as a compiled binary
>> or source code.
>>
>> There is no simple way to do this. It's an unfortunate bug, but it's
>> rare, and is dependent on the exact compilation process.
>>
>> The simplest way to detect a possible problem might be to compile the
>> package with both 1.15.10 and 1.15.11 and compare the generated
>> output.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/28J9lE4yoHI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/f3b69bbf-3a13-4786-924c-0e874c49ffd9n%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/CAJsvqr1cc1ye6V%3DXLPi9qjWe5aa5%3DRkW0pLRM6vTsn-W_5u83Q%40mail.gmail.com.

Re: [go-nuts] Modules... why it has to be so painfull?

[Slawomir Pryczek]

Thanks for all replies. Actually the docs are good (imo) just these  
solutions proposed in docs are a horror.

Inside root folder of the module... so im unable to share packages between 
projects and code structure gets horrible, because now instead of nicely 
organized 2 levels of nesting i have 3 levels and i need to repeat name of 
the project 5 times inside every of 25 different root packages. Maybe for 
small  apps. If i'm having eg. slab allocator used by both webserver and 
k-v storage it'd be good to put it outside and not having half of the 
modules in other apps imported from webserver and other half from k-v 
storage. It introduces unneeded complexity if package pretends to have 
something in common with something which is totally unrelated just because 
it's easier to put it in there. Next i'll have to do v2 of webserver when 
API of some of packages will change, so the version number won't reflect 
version number of my app... but changes to some single package in it.

Putting main app dir/files as a parent of general purpose packages is a bad 
idea. Having tax app to be a parent of decimals package is like having a 3d 
graph library to be a parent of network I/O package. There is no relation 
so it should be separated for readability.

>Have you tried go mod edit -replace github.com/foo/bar=/path/to/local/bar ?
I'll have to do hundreds of such edits and then re-edit it each time 
anything changes (package rename, moving files, etc.)

My point is why this module approach broken the ability to organize code 
conviniently and logically... If we're in /src/foo and there is /src/bar 
and we do import "bar" in foo... it should just (what a surprise) import 
the local bar :D And another issue with this approach is that... should we 
put this abomination inside git? So really, everyone who downloads my code 
will have to waste 4 hours of his life replacing imports or he'll be forced 
to do edits inside C:\Users\slawomir\go or maybe he'll edit in 
F:\users\michael\my\nice\go\path and put it in repo so i'll have to change 
it back :D

I know it's easier said than done but we have all this nice things like 
goroutines, GC, channels, peemption... and everything is so simple. Just to 
manually babysit package manager when previous model was working? Even 
having the user go to command line and issue module init for something 
without remote imports is a step backwards, because it's a waste of time, 
added complexity and totally unneeded.

Having like tens of pages of "instructions" and blog posts telling users 
how to configure package manager just to run 10 lines of code if we want to 
organize it well is a step forward? With GOPATH you did one simple thing 
and it was working. Just once not 1000 times over and over, for each 
package or after anything in your dev enviroment changed. So not sure why 
everyone should be forced to migrate to this cumbersome model when we have 
nicely organized, self containted projects and the only issue is versioning 
for the PART of projects which are actually ... libraries, not applications.

>One solution is apparently to use a module like a giant mono repo, aka 
gopath
Still it requires for this replace and keeping absolute paths everywhere. 
It's not even possible to put your project on github this way because it 
won't compile without configuring everything. That's a huge regression 
because you'll have to copy-paste all shared code inside each individual 
app folder if you don't want to publish 30 packages as separate modules or 
put unrelated things together. Each solution is sub-optimal because 
separation can't just be done right in sane amount of time in this model 
because PM isn't able to conviniently handle local packages nor 
initialization nor changes in the packages...

My point is, that it's so inconvinient that you'll organize your code badly 
just to save time... GOPATH is much better approach for bigger apps and it 
shouldn't be made obsolete. At least not if the only solution is putting 
things where they don't belong or setting up proxies to pretend local files 
are remote and then re-running some command line tools each time you add a 
line in one of these...

środa, 7 kwietnia 2021 o 23:55:03 UTC+2 m8il...@gmail.com napisał(a):

>
>> https://golang.org/ref/mod
>
> The how to code docs need improving for packages but once you initialise a 
> module. You can create folders to hold different packages within the root 
> folder containing the .mod file. I'm not sure modules are not a regression 
> compared to gopath in some respects though? One solution is apparently to 
> use a module like a giant mono repo, aka gopath.  I never used gopath 
> extensively myself.
>

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

Re: [go-nuts] package is not in GOROOT

[rob]

Yes, you are absolutely correct that I've been struggling w/ modules.

Would it be a bad idea to use my ~go/src as a module?

  cd ~/go/src

  go mod init src

  go mod tidy --> do I need this?

And then I would have to edit my import statements slightly to include 
the module reference.


--rob solomon


On 4/7/21 10:24 AM, wagner riffel wrote:

Hi Rob, it's good that you got it working, but I feel you're struggling
with modules inferred from your past emails due a confusion between a
module namespace and the file system, your package import paths and go
commands are relative to a *module* and not a directory, your current
module namespace is detected similarly as a git repository is, that is,
traverse current working directory up until a go.mod is found (or .git
for git), and then if a module is found, you import packages or use the
go commands in the format of *module_name*/folder/..., not file system
paths, what go cares as a namespace is the module name, not
absolute/relative file system paths.

For example, suppose our current working directory is "~/gcode/" and it
has a go.mod named¹ "foo", note that the folder is named gcode but the
module is "foo", you would install the "rpng" package inside this
module namespace "foo" with:
$ go install foo/rpng

you can refer file path relatives alike as well:
$ go install ./rpng # OK
$ go install rpng # invalid, would fail with the same not found message

you can think as dot expanding to "foo", not the file system gcode
folder, to make clear that it's not about file system paths, changing
our current working directory to "tokenize", we still can mention "rpng"
relative to the module, not the file system:
$ cd ~/gcode/tokenize
$ go install foo/rpng
$ go install ../rpng # valid as well

I'm not sure if this helps you or causes even more confusions, if so
sorry.

BR.

--wagner

[1] the module name is usually a domain, but not necessarily, refer to
https://pkg.go.dev/golang.org/x/mod/module#CheckPath for detailed
description.


--
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/e5b963f1-ea49-3323-8512-29bb151bfe34%40fastmail.com.

Re: [go-nuts] Strange behaviour with loops #45192, #45175

['Keith Randall' via golang-nuts]

If you look at CL 304251, there's one place where we added "return false". 
Put a panic just before that line (in 1.15.11 or 1.16.3), rebuild the 
compiler, then rebuild your program and see if your program triggers that 
panic.


On Wednesday, April 7, 2021 at 2:37:53 PM UTC-7 Ian Lance Taylor wrote:

> On Wed, Apr 7, 2021 at 1:47 PM sro...@gmail.com  wrote:
> >
> > Is there a way to analyze a go program and determine whether it is 
> susceptible to bug https://github.com/golang/go/issues/45175?
> > While the obvious solution is to upgrade to 1.15.11 or 1.16.3, it would 
> still be useful to analyze existing programs, either as a compiled binary 
> or source code.
>
> There is no simple way to do this. It's an unfortunate bug, but it's
> rare, and is dependent on the exact compilation process.
>
> The simplest way to detect a possible problem might be to compile the
> package with both 1.15.10 and 1.15.11 and compare the generated
> output.
>
> 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/f3b69bbf-3a13-4786-924c-0e874c49ffd9n%40googlegroups.com.

[go-nuts] Releasing a V2 module and interacting with git branches

[Marcin Romaszewicz]

Hi All,

I need to release a V2 of my module. (
https://github.com/deepmap/oapi-codegen). I understand what to do on the Go
side in terms of the /v2 suffix and go.mod changes, but I'm a little bit
unclear how this works w.r.t git branches. Yes, I've looked at
https://golang.org/ref/mod#vcs-find

My plan is to do development in a "v2" branch, which which will
occasionally be rebased onto the "master" branch until that's no longer
feasible, at which point I'll cherry pick or port important commits from
master to v2.

The v2 branch will start off with an annotated tag named "v2.0.0-alpha".
and will begin to diverge from master, which is tagged with v1.x.x

When I am ready to release the V2 branch, I plan to do the following.

Top commit in master becomes a new branch, "v1", and any future V1 bug
fixes go here.

I will merge the V2 branch into master, and tag it as v2.0.0.

Does this sounds like a reasonable plan? I would like, for the time being,
for people to be able to work on V1 in master, and eventually master will
become V2 while V1 is a branch.

My alternative is to create a V1 branch today, and all future work in
master is V2.

-- Marcin

-- 
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/CA%2Bv29LuBN-Z8V9xmkzNM1DmMowjtV4XsqOboRtY9pO%2BGYZ5ufw%40mail.gmail.com.

Re: [go-nuts] Big variations in benchmarking results ?

[Robert Engels]

OSX has a very different scheduler and often many more background processes. 
Also, you need to ensure you are running on the exact same chipset due to 
variations in cpu cache sizes and implementations. 

> On Apr 7, 2021, at 12:27 PM, christoph...@gmail.com 
>  wrote:
> 
> Hello,
> 
> I'm benchmarking some code with my mac book air. The code is only computation 
> and writing in a preallocated slice. I see big variations in the ns/op (e.g. 
> 5000 to 8000). I disabled the turbo boost but the variations are still there.
> 
> To verify I tried the code benchmarking on an Ubuntu desktop computer and the 
> variations are small (e.g. 4000 +/- 100 at most). 
> 
> What could explain these variations ? Is there a way to avoid it ?
> -- 
> 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/01c4cc10-b602-4cad-b369-3e410b563c6an%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/11CA6C52-E132-43B2-9244-CBF85804ECC1%40ix.netcom.com.

[go-nuts] Re: gRPC golang server and client testing

[Yijun Liu]

Hi, did you know how to do the unit testing of grpc now?

On Saturday, April 23, 2016 at 1:31:19 PM UTC-6 Sankar wrote:

> Hi
>
> I have a .proto file which I ran with protoc to generate the _pb.go file. 
> I then wrote a server and a client program that uses the above _pb.go 
> program. Now what is the best way to unit test the server and client pieces 
> ? (complete with mocking, benchmarks for both client and server; end-to-end 
> testing, etc.)
>
> IOW, I am trying to find out the test programs for 
> https://github.com/grpc/grpc-go/blob/master/examples/helloworld/greeter_server/main.go
>  
> and 
> https://github.com/grpc/grpc-go/blob/master/examples/helloworld/greeter_client/main.go
>  
>
> Thanks.
>
> Sankar
>

-- 
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/3b3d0712-f7ee-4368-8768-bcf649b0ba45n%40googlegroups.com.

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

[Ian Lance Taylor]

On Wed, Apr 7, 2021 at 4:47 AM Shiva  wrote:
>
> Thanks, Ian. Another step closer. Should the build statement just say:
>
> +build nsx
>
> Or should it be subject to any other rule, because I see a lot of different 
> build statements in each of those directories and they vary.

As a general guideline, follow the pattern of the existing files.

If there is a case that is unclear, let us know.

Ian


> On Wednesday, March 24, 2021 at 6:44:00 PM UTC Ian Lance Taylor wrote:
>>
>> On Wed, Mar 24, 2021 at 11:18 AM Shiva  wrote:
>> >
>> > Thank you for that, Ian.
>> >
>> > Just to confirm, I see the following -
>> >
>> > *_linux.c,
>> > *_linux.h,
>> > *_linux.go,
>> > *_linux.s,
>> > *_linux.pl
>> >
>> > They are in different directories - crypto, internal\syscall, net, os, 
>> > runtime, sync\atomic and syscall under the src directory. But you had 
>> > earlier mentioned only runtime and syscall packages so do I have to add 
>> > the rest too?
>> >
>> > After this I suppose I run bootstrap.bash which should create a go package 
>> > that I should try and run on the Nonstop.
>>
>> In the long run you will most likely have to handle all of those one
>> way or another, yes. Except probably for mksysnum_linux.pl.
>>
>> Ian
>>
>>
>>
>> > On Tuesday, March 23, 2021 at 6:51:55 PM UTC Ian Lance Taylor wrote:
>> >>
>> >> On Tue, Mar 23, 2021 at 9:41 AM Shiva  wrote:
>> >> >
>> >> > Trying to pick this up where it was left, we have the list of files 
>> >> > *_linux.go, *_linux.s but not all of them have the build statements, do 
>> >> > we create new nsx files only for those which have build statements in 
>> >> > them or for all of those files?
>> >>
>> >> For all of them. And add build tags to all of them. The use of build
>> >> tags in *_linux files is not consistent because the go tool has always
>> >> recognized *_linux file names specially.
>> >>
>> >> Ian
>> >>
>> >> > On Sunday, June 7, 2020 at 2:38:09 AM UTC+1 Ian Lance Taylor wrote:
>> >> >>
>> >> >> On Sat, Jun 6, 2020 at 8:57 AM Randall Becker  
>> >> >> wrote:
>> >> >> >
>> >> >> > Thanks. Where do fix the linker. I found the files to modify - so 
>> >> >> > will basically copy the *_linux.go, *_linux.s in both runtime and 
>> >> >> > syscalls to *_nsx.go and *_nsx.s, replacing +build lines with nsx 
>> >> >> > instead of linux, I assume. Currently looking for an assembler 
>> >> >> > cross-compiler for the platform (I may have to write one, something 
>> >> >> > I'm much more comfortable with than the GO port) - I can wrap asm in 
>> >> >> > C code, but I don't know how to get GO to recognize that.
>> >> >>
>> >> >> Go uses its own assembler, in cmd/asm.
>> >> >>
>> >> >> Ian
>> >> >>
>> >> >>
>> >> >> > On Friday, 5 June 2020 19:03:07 UTC-4, Ian Lance Taylor wrote:
>> >> >> >>
>> >> >> >> On Fri, Jun 5, 2020 at 3:46 PM Randall Becker  
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > That's actually what I figured. So where do I look to add nsx to 
>> >> >> >> > the toolchain?
>> >> >> >>
>> >> >> >> You'll have to fix the linker to generate whatever nsx expects.
>> >> >> >> You'll have to add code to support nsx in the runtime and syscall
>> >> >> >> packages. Pick which supported OS is most like nsx; let's say it's
>> >> >> >> linux. Look for *_linux.go and *_linux.s files; you'll need nsx
>> >> >> >> versions of those files. Look for +build lines in files that say
>> >> >> >> linux; you'll need to add nsx, or write a separate file that works 
>> >> >> >> on
>> >> >> >> nsx.
>> >> >> >>
>> >> >> >> It's a lot of work.
>> >> >> >>
>> >> >> >> Ian
>> >> >> >>
>> >> >> >>
>> >> >> >> > On Friday, 5 June 2020 17:03:11 UTC-4, Ian Lance Taylor wrote:
>> >> >> >> >>
>> >> >> >> >> On Fri, Jun 5, 2020 at 12:49 PM Randall Becker 
>> >> >> >> >>  wrote:
>> >> >> >> >> >
>> >> >> >> >> > Some progress. I've managed to build 1.14.4 using the Windows 
>> >> >> >> >> > GO implementation. The trouble I was having was using 
>> >> >> >> >> > cygwin64. After figuring that part out...
>> >> >> >> >> >
>> >> >> >> >> > I checked out a new branch from release_go1.14 named 
>> >> >> >> >> > nonstop_port
>> >> >> >> >> >
>> >> >> >> >> > Then ran
>> >> >> >> >> >
>> >> >> >> >> > GOARCH=amd64 GOOS=nsx bootstrap.bash
>> >> >> >> >> > which failed because I am using cygwin64, but then ran 
>> >> >> >> >> > make.bat from inside ../../go-nsx-amd64-bootstrap
>> >> >> >> >> > That installed a go binary in go-nsx-amd64-bootstrap/bin
>> >> >> >> >> >
>> >> >> >> >> > This still used the whatever compiler it chose to use, 
>> >> >> >> >> > presumably gcc-generated code, but the executable will not run 
>> >> >> >> >> > on the NonStop platform at all. The key here is that I need to 
>> >> >> >> >> > use c99 for cross-compilation.
>> >> >> >> >> >
>> >> >> >> >> > Where do I go next, please?
>> >> >> >> >>
>> >> >> >> >> I'm sure how to answer that except to say that you need to add 
>> >> >> >> >> support
>> >> >> >> >> for nsx to the Go toolchain. The Go toolchain is written in Go, 

Re: [go-nuts] Modules... why it has to be so painfull?

[Kevin Chadwick]

>
>
> https://golang.org/ref/mod

The how to code docs need improving for packages but once you initialise a
module. You can create folders to hold different packages within the root
folder containing the .mod file. I'm not sure modules are not a regression
compared to gopath in some respects though? One solution is apparently to
use a module like a giant mono repo, aka gopath.  I never used gopath
extensively myself.

-- 
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/CANNfpqeQT2HX82UERnX1YXYD-sx4s%3DMFwWx2Urh%3DhzSjddi84w%40mail.gmail.com.

Re: [go-nuts] Modules... why it has to be so painfull?

[Alex Howarth]

Have you tried go mod edit -replace github.com/foo/bar=/path/to/local/bar ?

https://golang.org/ref/mod#go-mod-edit

On Wed, 7 Apr 2021 at 17:31, Slawomir Pryczek  wrote:
>
> Hey Guys, I'm struggling with the new "modules" approach and after
checking several help files it seems it's inconvinient beyond belief.
Basically i have an app:
>
> ...src/
> /myapp/main.go package main
> /pool/pool.go package pool
>
> And i can't even include package pool into main without manually
initializing module, then installing it, and then when i do any change to
pool i'll have to re-get / re-install the package, so it even breaks things
as simple as conviniently building a basic app with >1 shared package.
>
> Question is why it's no longer possible to break the project into
independent packages and easily re-use them. I have eg. a webserver which
implements each operation as separate package, and also it has slab
allocator which other projects are using. And it works great.
>
> Maybe someday i'd like to convert the slab allocator into separated
module, but why forcing users to do so much unnecessary work and pretend
everyone wants to expose everything they're writing as module from earliest
stage of the project?
>
> Is there any way to retain this kind of structure without countless hours
wasted on manually initializing modules and other completely pointless
maintenance tasks. Previously i was just able to create a package in gopath
and use it everywhere, refactoring was very easy and i could easily split
any project into multiple packages. Actually go was so good because
refactoring and reorganizing code was so easy. Now it seems that's no
longer possible and in docs I found info that gopath approach will be
obsolete, so i'm trying to go with the new one. Which seems so painfull...
>
> Also read several posts about local packages. Complexity of this is
beyond ridiculous. Really i need to install a local proxy or use some
special directives to allow my appa and appb to use packagec? Really it
needs to be so complex and so user unfriendly so instead of writing code
we'll be thinking about setting up proxies and configuring dependencies
just to share some code between 2 local apps because this has to be done
via HTTP or special configuration?
>
> Anyone has an idea for a reasonable solution which will allow easy
refactoring and code organization in packages, in this new model?
>
> Thanks,
> Slawomir.
>
> --
> 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/bb6d0bd0-e411-4c93-a1ee-5eec44e1bc48n%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/CAB-c0PcAp09JJEZvMgPLM%3Dqm2rjzxX0V6iw0y2m-kZ5KNYQEdQ%40mail.gmail.com.

Re: [go-nuts] Strange behaviour with loops #45192, #45175

[Ian Lance Taylor]

On Wed, Apr 7, 2021 at 1:47 PM sro...@gmail.com  wrote:
>
> Is there a way to analyze a go program and determine whether it is 
> susceptible to bug https://github.com/golang/go/issues/45175?
> While the obvious solution is to upgrade to 1.15.11 or 1.16.3, it would still 
> be useful to analyze existing programs, either as a compiled binary or source 
> code.

There is no simple way to do this.  It's an unfortunate bug, but it's
rare, and is dependent on the exact compilation process.

The simplest way to detect a possible problem might be to compile the
package with both 1.15.10 and 1.15.11 and compare the generated
output.

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/CAOyqgcX2n%2BeGy8RG9-9jG%2BeOo8%2B8hRqT1R2Qg9TVM01iwOqzhQ%40mail.gmail.com.

[go-nuts] Modules... why it has to be so painfull?

[Slawomir Pryczek]

Hey Guys, I'm struggling with the new "modules" approach and after checking 
several help files it seems it's inconvinient beyond belief. Basically i 
have an app:

...src/
/myapp/main.go package main
/pool/pool.go package pool

And i can't even include package pool into main without manually 
initializing module, then installing it, and then when i do any change to 
pool i'll have to re-get / re-install the package, so it even breaks things 
as simple as conviniently building a basic app with >1 shared package.

Question is why it's no longer possible to break the project into 
independent packages and easily re-use them. I have eg. a webserver which 
implements each operation as separate package, and also it has slab 
allocator which other projects are using. And it works great.

Maybe someday i'd like to convert the slab allocator into separated module, 
but why forcing users to do so much unnecessary work and pretend everyone 
wants to expose everything they're writing as module from earliest stage of 
the project?

Is there any way to retain this kind of structure without countless hours 
wasted on manually initializing modules and other completely pointless 
maintenance tasks. Previously i was just able to create a package in gopath 
and use it everywhere, refactoring was very easy and i could easily split 
any project into multiple packages. Actually go was so good because 
refactoring and reorganizing code was so easy. Now it seems that's no 
longer possible and in docs I found info that gopath approach will be 
obsolete, so i'm trying to go with the new one. Which seems so painfull...

Also read several posts about local packages. Complexity of this is beyond 
ridiculous. Really i need to install a local proxy or use some special 
directives to allow my appa and appb to use packagec? Really it needs to be 
so complex and so user unfriendly so instead of writing code we'll be 
thinking about setting up proxies and configuring dependencies just to 
share some code between 2 local apps because this has to be done via HTTP 
or special configuration?

Anyone has an idea for a reasonable solution which will allow easy 
refactoring and code organization in packages, in this new model?

Thanks,
Slawomir.

-- 
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/bb6d0bd0-e411-4c93-a1ee-5eec44e1bc48n%40googlegroups.com.

[go-nuts] Strange behaviour with loops #45192, #45175

[sro...@gmail.com]

Is there a way to analyze a go program and determine whether it is 
susceptible to bug https://github.com/golang/go/issues/45175?
While the obvious solution is to upgrade to 1.15.11 or 1.16.3, it would 
still be useful to analyze existing programs, either as a compiled binary 
or source code.
Thank you. Sebastien

-- 
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/2818753d-406e-4a46-bc32-d52338614140n%40googlegroups.com.

[go-nuts] Big variations in benchmarking results ?

[christoph...@gmail.com]

Hello,

I'm benchmarking some code with my mac book air. The code is only 
computation and writing in a preallocated slice. I see big variations in 
the ns/op (e.g. 5000 to 8000). I disabled the turbo boost but the 
variations are still there. 

To verify I tried the code benchmarking on an Ubuntu desktop computer and 
the variations are small (e.g. 4000 +/- 100 at most). 

What could explain these variations ? Is there a way to avoid it ?

-- 
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/01c4cc10-b602-4cad-b369-3e410b563c6an%40googlegroups.com.

Re: [go-nuts] package is not in GOROOT

[rob]

It does help me. 

Thanks 

-- 
  rob
  drrob...@fastmail.com

On Wed, Apr 7, 2021, at 10:24 AM, wagner riffel wrote:
> On Tue, 6 Apr 2021 19:39:00 -0400
> rob  wrote:
> 
> >  > This example is on Win10 using go 1.16.3
> > 
> > Now I've created a directory tree outside of ~/go/src.  I'm using ~
> > to mean %userprofile%, as this is win10
> > 
> > ~/gcode/rpng/rpng.go
> > 
> > ~/gcode/tokenize/tokenize.go
> > 
> > ~/gcode/hpcalc2/hpcalc2.go
> > 
> > And I updated my import statement to be "gcode/hpcalc2", etc.
> > 
> > Now I can use
> > 
> >   go run gcode/rpng/rpng.go
> > 
> > And I set GOBIN=c:\Users\rob\gcode
> > 
> >      go install gcode/rpng/rpng.go
> > 
> > and it installs to GOBIN.
> > 
> > At least it's working for me mostly the way it was before.  I just
> > had to abandon my ~/go directory
> > 
> > Thanks for answering
> > 
> > Rob
> > 
> 
> Hi Rob, it's good that you got it working, but I feel you're struggling
> with modules inferred from your past emails due a confusion between a
> module namespace and the file system, your package import paths and go
> commands are relative to a *module* and not a directory, your current
> module namespace is detected similarly as a git repository is, that is,
> traverse current working directory up until a go.mod is found (or .git
> for git), and then if a module is found, you import packages or use the
> go commands in the format of *module_name*/folder/..., not file system
> paths, what go cares as a namespace is the module name, not
> absolute/relative file system paths.
> 
> For example, suppose our current working directory is "~/gcode/" and it
> has a go.mod named¹ "foo", note that the folder is named gcode but the
> module is "foo", you would install the "rpng" package inside this
> module namespace "foo" with:
> $ go install foo/rpng
> 
> you can refer file path relatives alike as well:
> $ go install ./rpng # OK
> $ go install rpng # invalid, would fail with the same not found message
> 
> you can think as dot expanding to "foo", not the file system gcode
> folder, to make clear that it's not about file system paths, changing
> our current working directory to "tokenize", we still can mention "rpng"
> relative to the module, not the file system:
> $ cd ~/gcode/tokenize
> $ go install foo/rpng
> $ go install ../rpng # valid as well
> 
> I'm not sure if this helps you or causes even more confusions, if so
> sorry.
> 
> BR.
> 
> --wagner
> 
> [1] the module name is usually a domain, but not necessarily, refer to
> https://pkg.go.dev/golang.org/x/mod/module#CheckPath for detailed
> description.
>

-- 
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/47d67ccf-1d85-4bb2-9555-cf7ee4a8f9b0%40www.fastmail.com.

Re: [go-nuts] package is not in GOROOT

['wagner riffel' via golang-nuts]

On Tue, 6 Apr 2021 19:39:00 -0400
rob  wrote:

>  > This example is on Win10 using go 1.16.3
> 
> Now I've created a directory tree outside of ~/go/src.  I'm using ~
> to mean %userprofile%, as this is win10
> 
> ~/gcode/rpng/rpng.go
> 
> ~/gcode/tokenize/tokenize.go
> 
> ~/gcode/hpcalc2/hpcalc2.go
> 
> And I updated my import statement to be "gcode/hpcalc2", etc.
> 
> Now I can use
> 
>   go run gcode/rpng/rpng.go
> 
> And I set GOBIN=c:\Users\rob\gcode
> 
>      go install gcode/rpng/rpng.go
> 
> and it installs to GOBIN.
> 
> At least it's working for me mostly the way it was before.  I just
> had to abandon my ~/go directory
> 
> Thanks for answering
> 
> Rob
> 

Hi Rob, it's good that you got it working, but I feel you're struggling
with modules inferred from your past emails due a confusion between a
module namespace and the file system, your package import paths and go
commands are relative to a *module* and not a directory, your current
module namespace is detected similarly as a git repository is, that is,
traverse current working directory up until a go.mod is found (or .git
for git), and then if a module is found, you import packages or use the
go commands in the format of *module_name*/folder/..., not file system
paths, what go cares as a namespace is the module name, not
absolute/relative file system paths.

For example, suppose our current working directory is "~/gcode/" and it
has a go.mod named¹ "foo", note that the folder is named gcode but the
module is "foo", you would install the "rpng" package inside this
module namespace "foo" with:
$ go install foo/rpng

you can refer file path relatives alike as well:
$ go install ./rpng # OK
$ go install rpng # invalid, would fail with the same not found message

you can think as dot expanding to "foo", not the file system gcode
folder, to make clear that it's not about file system paths, changing
our current working directory to "tokenize", we still can mention "rpng"
relative to the module, not the file system:
$ cd ~/gcode/tokenize
$ go install foo/rpng
$ go install ../rpng # valid as well

I'm not sure if this helps you or causes even more confusions, if so
sorry.

BR.

--wagner

[1] the module name is usually a domain, but not necessarily, refer to
https://pkg.go.dev/golang.org/x/mod/module#CheckPath for detailed
description.

-- 
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/20210407112419.1e5e0132%40pampas.

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

[Shiva]

Thanks, Ian. Another step closer. Should the build statement just say: 

+build nsx 

Or should it be subject to any other rule, because I see a lot of different 
build statements in each of those directories and they vary.

On Wednesday, March 24, 2021 at 6:44:00 PM UTC Ian Lance Taylor wrote:

> On Wed, Mar 24, 2021 at 11:18 AM Shiva  wrote:
> >
> > Thank you for that, Ian.
> >
> > Just to confirm, I see the following -
> >
> > *_linux.c,
> > *_linux.h,
> > *_linux.go,
> > *_linux.s,
> > *_linux.pl
> >
> > They are in different directories - crypto, internal\syscall, net, os, 
> runtime, sync\atomic and syscall under the src directory. But you had 
> earlier mentioned only runtime and syscall packages so do I have to add the 
> rest too?
> >
> > After this I suppose I run bootstrap.bash which should create a go 
> package that I should try and run on the Nonstop.
>
> In the long run you will most likely have to handle all of those one
> way or another, yes. Except probably for mksysnum_linux.pl.
>
> Ian
>
>
>
> > On Tuesday, March 23, 2021 at 6:51:55 PM UTC Ian Lance Taylor wrote:
> >>
> >> On Tue, Mar 23, 2021 at 9:41 AM Shiva  wrote:
> >> >
> >> > Trying to pick this up where it was left, we have the list of files 
> *_linux.go, *_linux.s but not all of them have the build statements, do we 
> create new nsx files only for those which have build statements in them or 
> for all of those files?
> >>
> >> For all of them. And add build tags to all of them. The use of build
> >> tags in *_linux files is not consistent because the go tool has always
> >> recognized *_linux file names specially.
> >>
> >> Ian
> >>
> >> > On Sunday, June 7, 2020 at 2:38:09 AM UTC+1 Ian Lance Taylor wrote:
> >> >>
> >> >> On Sat, Jun 6, 2020 at 8:57 AM Randall Becker  
> wrote:
> >> >> >
> >> >> > Thanks. Where do fix the linker. I found the files to modify - so 
> will basically copy the *_linux.go, *_linux.s in both runtime and syscalls 
> to *_nsx.go and *_nsx.s, replacing +build lines with nsx instead of linux, 
> I assume. Currently looking for an assembler cross-compiler for the 
> platform (I may have to write one, something I'm much more comfortable with 
> than the GO port) - I can wrap asm in C code, but I don't know how to get 
> GO to recognize that.
> >> >>
> >> >> Go uses its own assembler, in cmd/asm.
> >> >>
> >> >> Ian
> >> >>
> >> >>
> >> >> > On Friday, 5 June 2020 19:03:07 UTC-4, Ian Lance Taylor wrote:
> >> >> >>
> >> >> >> On Fri, Jun 5, 2020 at 3:46 PM Randall Becker  
> wrote:
> >> >> >> >
> >> >> >> > That's actually what I figured. So where do I look to add nsx 
> to the toolchain?
> >> >> >>
> >> >> >> You'll have to fix the linker to generate whatever nsx expects.
> >> >> >> You'll have to add code to support nsx in the runtime and syscall
> >> >> >> packages. Pick which supported OS is most like nsx; let's say it's
> >> >> >> linux. Look for *_linux.go and *_linux.s files; you'll need nsx
> >> >> >> versions of those files. Look for +build lines in files that say
> >> >> >> linux; you'll need to add nsx, or write a separate file that 
> works on
> >> >> >> nsx.
> >> >> >>
> >> >> >> It's a lot of work.
> >> >> >>
> >> >> >> Ian
> >> >> >>
> >> >> >>
> >> >> >> > On Friday, 5 June 2020 17:03:11 UTC-4, Ian Lance Taylor wrote:
> >> >> >> >>
> >> >> >> >> On Fri, Jun 5, 2020 at 12:49 PM Randall Becker <
> the@gmail.com> wrote:
> >> >> >> >> >
> >> >> >> >> > Some progress. I've managed to build 1.14.4 using the 
> Windows GO implementation. The trouble I was having was using cygwin64. 
> After figuring that part out...
> >> >> >> >> >
> >> >> >> >> > I checked out a new branch from release_go1.14 named 
> nonstop_port
> >> >> >> >> >
> >> >> >> >> > Then ran
> >> >> >> >> >
> >> >> >> >> > GOARCH=amd64 GOOS=nsx bootstrap.bash
> >> >> >> >> > which failed because I am using cygwin64, but then ran 
> make.bat from inside ../../go-nsx-amd64-bootstrap
> >> >> >> >> > That installed a go binary in go-nsx-amd64-bootstrap/bin
> >> >> >> >> >
> >> >> >> >> > This still used the whatever compiler it chose to use, 
> presumably gcc-generated code, but the executable will not run on the 
> NonStop platform at all. The key here is that I need to use c99 for 
> cross-compilation.
> >> >> >> >> >
> >> >> >> >> > Where do I go next, please?
> >> >> >> >>
> >> >> >> >> I'm sure how to answer that except to say that you need to add 
> support
> >> >> >> >> for nsx to the Go toolchain. The Go toolchain is written in 
> Go, not
> >> >> >> >> C, so the mention of c99 seems irrelevant. Your first step is 
> to
> >> >> >> >> build a Go toolchain that runs on your host system (not your 
> nsx
> >> >> >> >> system), which you've done. The second step is to add nsx 
> support to
> >> >> >> >> the toolchain. The third step is to run bootstrap.bash. The 
> fact
> >> >> >> >> that bootstrap.bash gives you a program that won't run on nsx 
> suggests
> >> >> >> >> that the second step is not complete.
> >> >> >> >>
> >> >> >> 

[go-nuts] Re: Calling Go from Python

[Amit Lavon]

Thanks!
Gopy seemed promising back when I started exploring this topic, but I had 
some issues getting it to work, especially on Windows. It may have gotten 
better by now. Anyway I agree it's beneficial to have both approaches 
available so I am happy to see gopy grow as well.
On Wednesday, April 7, 2021 at 8:10:03 AM UTC+3 Justin Israel wrote:

> On Wednesday, April 7, 2021 at 6:10:49 AM UTC+12 amitl...@gmail.com wrote:
>
>>
>> Hi,
>> A cheat-sheet I wrote for myself evolved into a full tutorial 
>>  on calling Go directly from Python 
>> using ctypes and dll's, so I am happy to share it with the community. It 
>> starts from the very basics and covers how to handle arrays, strings and 
>> objects in both directions, memory management, performance, and even how to 
>> interact directly with numpy and pandas objects. I hope it's useful for the 
>> pythonistas among you.
>>
>> Any feedback, ideas and questions are welcome.
>>
>
> Nice write up! I've use the ctypes approach for a few situations and its 
> great to have a detailed reference guide like this. 
>
> Also recently I started using https://github.com/go-python/gopy and have 
> been contributing a bunch of fixes and features. For simple situations 
> though it is much easier to just use the ctypes approach since you have 
> fine grained control over the access. As long has you don't have too much 
> to expose to python, and too much memory management and type shimming to do.
>  
>
>>
>> Amit
>>
>

-- 
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/9621c43b-720e-40f8-9ea3-74366032e66cn%40googlegroups.com.