[go-nuts] Re: 1.13.4: go mod: weird permissions in pkg/mod after go get

[clement auger]

in regard of Sean comment and FTR, 

Now using version go1.13.4
[clementauger@Host-001 ~] $ ll gow/
bin/ pkg/ src/ 
[clementauger@Host-001 ~] $ ll gow/
bin/ pkg/ src/ 
[clementauger@Host-001 ~] $ ll gow/pkg/mod/
cache/  github.com/ golang.org/ gopkg.in/   
[clementauger@Host-001 ~] $ ll gow/pkg/mod/github.com/apex/
total 4
dr-xr-xr-x 5 clementauger clementauger 4096 15 oct.  21:00 log@v1.1.1
[clementauger@Host-001 ~] $ ll gow/pkg/mod/github.com/apex/*/*
-r--r--r--  1 clementauger clementauger  794 15 oct.  21:00 
gow/pkg/mod/github.com/apex/log@v1.1.1/default.go
-r--r--r--  1 clementauger clementauger  430 15 oct.  21:00 
gow/pkg/mod/github.com/apex/log@v1.1.1/doc.go

$ ll gow/pkg/mod/github.com/hashicorp/
total 8
dr-x-- 2 clementauger clementauger 4096 22 nov.  20:35 errwrap@v1.0.0
dr-x-- 2 clementauger clementauger 4096 22 nov.  20:35 
go-multierror@v1.0.0

$ ll gow/pkg/mod/github.com/hashicorp/*/*
-r--r--r-- 1 clementauger clementauger  4377 22 nov.  20:35 gow/pkg/mod/
github.com/hashicorp/errwrap@v1.0.0/errwrap.go
-r--r--r-- 1 clementauger clementauger  1292 22 nov.  20:35 gow/pkg/mod/
github.com/hashicorp/errwrap@v1.0.0/errwrap_test.go
-r--r--r-- 1 clementauger clementauger36 22 nov.  20:35 gow/pkg/mod/
github.com/hashicorp/errwrap@v1.0.0/go.mod
-r--r--r-- 1 clementauger clementauger 15977 22 nov.  20:35 gow/pkg/mod/
github.com/hashicorp/errwrap@v1.0.0/LICENSE




Le vendredi 22 novembre 2019 20:40:56 UTC+1, clement auger a écrit :
>
> hi,
>
> I have some weird permissions set on my module files after i run go get on 
> my project.
>
> please check my session
>
> [clementauger@Host-001 jenjen-stream] $ go version
> go version go1.13.4 linux/amd64
> [clementauger@Host-001 jenjen-stream] $ go env
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/clementauger/.cache/go-build"
> GOENV="/home/clementauger/.config/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/home/clementauger/gow"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct;
> GOROOT="/home/clementauger/.gvm/gos/go1.13.4"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/home/clementauger/.gvm/gos/go1.13.4/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD="/home/clementauger/gow/src/
> github.com/clementauger/jenjen-stream/go.mod"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build597193614=/tmp/go-build 
> -gno-record-gcc-switches"
> [clementauger@Host-001 jenjen-stream] $ sudo rm -fr /home/clementauger/gow
> /pkg/mod/github.com/hashicorp/go-multierror@v1.0.0/
> [clementauger@Host-001 jenjen-stream] $ sudo rm -fr /home/clementauger/gow
> /pkg/mod/github.com/hashicorp/errwrap@v1.0.0/
> [clementauger@Host-001 jenjen-stream] $ sudo rm -fr /home/clementauger/gow
> /pkg/mod/github.com/hashicorp/
> [clementauger@Host-001 jenjen-stream] $ cat go.mod 
> module github.com/clementauger/jenjen-stream
>
> go 1.13
>
> require github.com/hashicorp/go-multierror v1.0.0
> [clementauger@Host-001 jenjen-stream] $ go get ./...
> go: extracting github.com/hashicorp/go-multierror v1.0.0
> go: extracting github.com/hashicorp/errwrap v1.0.0
> [clementauger@Host-001 jenjen-stream] $ ll /home/clementauger/gow/pkg/mod/
> github.com/hashicorp/
> total 8
> dr-x-- 2 clementauger clementauger 4096 22 nov.  20:35 errwrap@v1.0.0
> dr-x-- 2 clementauger clementauger 4096 22 nov.  20:35 go-
> multierror@v1.0.0
>
> It also triggers a bug when i try to load that package using x/go/loader
>
> $ jenjen -template=github.com/clementauger/jenjen-stream -   "T => 
> string, StreamT => StreamString, stream => streamString"
> /home/clementauger/gow/pkg/mod/github.com/hashicorp/go-multierror@v1.0.0/
> prefix.go:6:2: could not import github.com/hashicorp/errwrap (go/build: 
> importGo github.com/hashicorp/errwrap: exit status 1
> error writing go.mod: open /home/clementauger/gow/pkg/mod/github.com/
> hashicorp/go-multierror@v1.0.0/go.mod298498081.tmp: permission denied
>
> )
> 2019/11/22 20:37:34 couldn't load packages due to errors: 
> github.com/hashicorp/go-multierror
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmen

[go-nuts] 1.13.4: x/go/loader: prevent update of the go.mod file ?

[clement auger]

hi,

I have met another issue with go.mod and x/go/loader.

It looks like when it loads, it updates the go.mod in cwd

in this example i create a new conf to load tpl package,
it results in running the loader in cwd,
because I call for Import(), it updates the go.mod
and the programmatically imported package as a dependency.

var conf loader.Config
conf.ParserMode = parser.ParseComments
conf.Import(tpl)
prog, err := conf.Load()
if err != nil {
log.Fatal(err)
}


but in this case it is not a dependency, it is just a random package i need 
load.

Can i do something to prevent that ?

thank you.

-- 
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/38921516-9986-4704-b402-5eea49ba75de%40googlegroups.com.

[go-nuts] 1.13.4: go mod: weird permissions in pkg/mod after go get

[clement auger]

hi,

I have some weird permissions set on my module files after i run go get on 
my project.

please check my session

[clementauger@Host-001 jenjen-stream] $ go version
go version go1.13.4 linux/amd64
[clementauger@Host-001 jenjen-stream] $ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/clementauger/.cache/go-build"
GOENV="/home/clementauger/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/clementauger/gow"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct;
GOROOT="/home/clementauger/.gvm/gos/go1.13.4"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/clementauger/.gvm/gos/go1.13.4/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=
"/home/clementauger/gow/src/github.com/clementauger/jenjen-stream/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build597193614=/tmp/go-build 
-gno-record-gcc-switches"
[clementauger@Host-001 jenjen-stream] $ sudo rm -fr /home/clementauger/gow/
pkg/mod/github.com/hashicorp/go-multierror@v1.0.0/
[clementauger@Host-001 jenjen-stream] $ sudo rm -fr /home/clementauger/gow/
pkg/mod/github.com/hashicorp/errwrap@v1.0.0/
[clementauger@Host-001 jenjen-stream] $ sudo rm -fr /home/clementauger/gow/
pkg/mod/github.com/hashicorp/
[clementauger@Host-001 jenjen-stream] $ cat go.mod 
module github.com/clementauger/jenjen-stream

go 1.13

require github.com/hashicorp/go-multierror v1.0.0
[clementauger@Host-001 jenjen-stream] $ go get ./...
go: extracting github.com/hashicorp/go-multierror v1.0.0
go: extracting github.com/hashicorp/errwrap v1.0.0
[clementauger@Host-001 jenjen-stream] $ ll /home/clementauger/gow/pkg/mod/
github.com/hashicorp/
total 8
dr-x-- 2 clementauger clementauger 4096 22 nov.  20:35 errwrap@v1.0.0
dr-x-- 2 clementauger clementauger 4096 22 nov.  20:35 go-multierror@v1.
0.0

It also triggers a bug when i try to load that package using x/go/loader

$ jenjen -template=github.com/clementauger/jenjen-stream -   "T => string, 
StreamT => StreamString, stream => streamString"
/home/clementauger/gow/pkg/mod/github.com/hashicorp/go-multierror@v1.0.0/
prefix.go:6:2: could not import github.com/hashicorp/errwrap (go/build: 
importGo github.com/hashicorp/errwrap: exit status 1
error writing go.mod: open /home/clementauger/gow/pkg/mod/github.com/
hashicorp/go-multierror@v1.0.0/go.mod298498081.tmp: permission denied

)
2019/11/22 20:37:34 couldn't load packages due to errors: 
github.com/hashicorp/go-multierror
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x647257]

goroutine 1 [running]:
golang.org/x/tools/go/loader.(*Program).InitialPackages(0x0, 0x1, 0x1, 
0xc00244fdf0)

/home/clementauger/gow/pkg/mod/golang.org/x/tools@v0.0.0-20191121172411-96ad48e4b060/go/loader/loader.go:372
 
+0x37
main.main()

/home/clementauger/gow/src/github.com/clementauger/jenjen/cmd/jenjen/main.go:132
 
+0x946

the conf is standard, where dst="."

var conf loader.Config
conf.FromArgs([]string{dst}, false)
prog, err := conf.Load()
if err != nil {
log.Println(err)
}
i := prog.InitialPackages()
if len(i) > 0 && len(i[0].Files) > 0 {
dstPkgName = i[0].Files[0].Name.Name
dstFp = prog.Fset.File(i[0].Files[0].Pos()).Name()
}

go.mod used to work well, what's wrong ?

-- 
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/1f704570-ae81-47b6-99a9-6d80bc9d5406%40googlegroups.com.

Re: [go-nuts] Re: Package-to-package bindings and package-scope variables

[clement auger]

hi Michel,

canonical import path ? 
https://golang.org/doc/go1.4#canonicalimports
https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7vYv5hWtPx9--lTx1gPMs/edit

you also might want to check,
https://github.com/golang/tools/tree/master/cmd/gomvpkg
https://github.com/golang/tools/tree/master/cmd/goimports
https://github.com/KSubedi/gomove


Le mardi 17 septembre 2019 10:34:36 UTC+2, Michel Levieux a écrit :

> Hi again Clément,
>
> It is indeed an uncommon practice, but I can explain my motivations behind 
> this little project:
> Where I work, we have a huge helper package with lots of sub-packages. 
> This package existed long before I started working there, and we (the devs) 
> knew it would be a problem at some point, having this giant package and its 
> sub-packages imported in almost all our projects. Lately I decided that it 
> was too much (we've been adding packages and features to it a lot the last 
> 6 months) and that it seriously needed splitting. So since every single 
> person who develops in the company uses this package, there is a strong 
> probability that many projects are not on my laptop and my IDE can't detect 
> them to update all the relevant import paths. But still, I'd like to be 
> able to improve our codebase without breaking everything, hence the 
> command. It is a really specific case, and I know that, but that's the best 
> solution I've come up with so far.
>
> Maybe I should've asked here about that before, rather than my original 
> question ^^'
>
> Anyways, thank you again for the time you give me, don't hesitate if you 
> have other ideas or questions. 
>
> As for the use of go.loader, I think I will switch to it when I really 
> understand go.ast and go.parser, the reason being I wanna understand the 
> most of what is going on under the hood before abstracting it :)
>
> Le lun. 16 sept. 2019 à 23:10, clement auger  > a écrit :
>
>> hi again,
>>
>> This looks odd use case because when i move a package around,
>> with all the great tooling provided by the contributors,
>> import paths are updated automatically after a save.
>> It fails only if the package name is ambiguous because it
>> exists twice with different package paths within the workspace.
>> Its a terribly boring issue when that happens,
>> but i managed to survive it.
>>
>> With a bit of research into those tools documentation,
>> a solution should quickly come up 
>> to recursively update a workspace.
>>
>> About the deprecation, i think it is strongly dependent
>> with your development practices and workflow.
>> If possible, I would not deprecate, but update my dependencies,
>> and pay my technical debts asap.
>>
>> As for go.loader, it is a high level API of go.ast, go.parser etc
>> As such it provides lots of help when you are dealing with
>> go language loading, parsing, interpreting, traversing and manipulation.
>> It is tremendously useful when, for example, 
>> cross package reference resolutions comes into your way.
>>
>> Regarding the linkname pragma, i don't know enough about
>> the process of compilation to tell you anything relevant to its usage.
>> However, i tried to "relink" a public var of a package
>> to another package public var, nothing happened.
>> More reasonably, this extract (
>> https://gist.github.com/myitcv/e4202a9513bed098262444ed0f4f3625)
>> of pragma usage within the core tree demonstrates
>> a pretty specific usage to inject public symbols of C funcs.
>> e.g. //go:linkname byteIndex strings.IndexByte
>>
>> Maybe someone else with a deeper knowledge can help you figure that out.
>>
>> I don't have the feeling that i answered your questions, sorry for that.
>>
>> Le lundi 16 septembre 2019 15:57:54 UTC+2, Michel Levieux a écrit :
>>>
>>> Hi Clément, thank you for your answer,
>>>
>>> Your links are pretty interesting, though maybe I was unclear stating my 
>>> issue because that is not what I was looking for.
>>> I also think such a tool should be used with parsimony, the goal being 
>>> that over time, people stop using the old package's location and it can be 
>>> removed.
>>>
>>> I also find it important to specify that my program documents the whole 
>>> new package as being deprecated, also informing the user where to find the 
>>> new package.
>>>
>>> However, what I'm having trouble with is that a modification of a 
>>> package scope variable in the newly created package will not result in a 
>>> modification of the aliased variable of the old package.
>>> I'm using the go/ast

Re: [go-nuts] Re: Package-to-package bindings and package-scope variables

[clement auger]

hi again,

This looks odd use case because when i move a package around,
with all the great tooling provided by the contributors,
import paths are updated automatically after a save.
It fails only if the package name is ambiguous because it
exists twice with different package paths within the workspace.
Its a terribly boring issue when that happens,
but i managed to survive it.

With a bit of research into those tools documentation,
a solution should quickly come up 
to recursively update a workspace.

About the deprecation, i think it is strongly dependent
with your development practices and workflow.
If possible, I would not deprecate, but update my dependencies,
and pay my technical debts asap.

As for go.loader, it is a high level API of go.ast, go.parser etc
As such it provides lots of help when you are dealing with
go language loading, parsing, interpreting, traversing and manipulation.
It is tremendously useful when, for example, 
cross package reference resolutions comes into your way.

Regarding the linkname pragma, i don't know enough about
the process of compilation to tell you anything relevant to its usage.
However, i tried to "relink" a public var of a package
to another package public var, nothing happened.
More reasonably, this extract 
(https://gist.github.com/myitcv/e4202a9513bed098262444ed0f4f3625)
of pragma usage within the core tree demonstrates
a pretty specific usage to inject public symbols of C funcs.
e.g. //go:linkname byteIndex strings.IndexByte

Maybe someone else with a deeper knowledge can help you figure that out.

I don't have the feeling that i answered your questions, sorry for that.

Le lundi 16 septembre 2019 15:57:54 UTC+2, Michel Levieux a écrit :
>
> Hi Clément, thank you for your answer,
>
> Your links are pretty interesting, though maybe I was unclear stating my 
> issue because that is not what I was looking for.
> I also think such a tool should be used with parsimony, the goal being 
> that over time, people stop using the old package's location and it can be 
> removed.
>
> I also find it important to specify that my program documents the whole 
> new package as being deprecated, also informing the user where to find the 
> new package.
>
> However, what I'm having trouble with is that a modification of a package 
> scope variable in the newly created package will not result in a 
> modification of the aliased variable of the old package.
> I'm using the go/ast and go/parser (along with a little of go/token) 
> packages for the parsing, processing and generation of the different 
> aspects of the packages.
>
> I saw some //go:linkname pragmas that seem to do what I want but I don't 
> wanna do things that are not recommended or unsafe, I want to be sure what 
> I'm doing is the right way to go, or at least that it's not possible with 
> the current state of the language.
>
>
>
> Le lun. 16 sept. 2019 à 15:10, clement auger  > a écrit :
>
>> hi,
>>
>> it seems you need 
>> https://godoc.org/golang.org/x/tools/go/loader
>> https://godoc.org/go/types
>>
>> then select desired package, get its top scope, loop over public names, 
>> generate aliases.
>>
>> but i m unsure it is such a good idea to keep those shallow copies 
>> around, at least for the case you have found out.
>>
>> Le lundi 16 septembre 2019 14:27:01 UTC+2, Michel Levieux a écrit :
>>>
>>> Hi all,
>>>
>>> I'm developing a command that is a utility to move packages around while 
>>> keeping compatibility with softwares that import those packages. Maybe 
>>> there are commands and utilities that already do approximately the same 
>>> thing, but I'm mainly doing this to learn to use the go/ast package and 
>>> everything. Let me give you a small example:
>>>
>>> - Let's say I have a package in my GOPATH that's named 'foo'
>>> - In this package there is another package 'bar', but this package bar 
>>> has grown a whole lot since the beginning of the project, and might as well 
>>> be a project on its own.
>>> - What I want is extract package 'bar' from 'foo' without having to go 
>>> through all other projects importing 'bar' to change import paths
>>> - The process for the command is to first move package 'bar' wherever I 
>>> tell it to move it and replace anything in previously existing package 
>>> 'foo/bar' with bindings, so any function's body is replaced with a call to 
>>> the function in the moved package, any type is transformed into an "alias" 
>>> of the moved package's corresponding type (TypeA = bar.TypeA), as well as 
>>> any constant or variable.
>>>
>>> The command is not finished yet but I'm runnin

[go-nuts] Re: Package-to-package bindings and package-scope variables

[clement auger]

hi,

it seems you need 
https://godoc.org/golang.org/x/tools/go/loader
https://godoc.org/go/types

then select desired package, get its top scope, loop over public names, 
generate aliases.

but i m unsure it is such a good idea to keep those shallow copies around, 
at least for the case you have found out.

Le lundi 16 septembre 2019 14:27:01 UTC+2, Michel Levieux a écrit :
>
> Hi all,
>
> I'm developing a command that is a utility to move packages around while 
> keeping compatibility with softwares that import those packages. Maybe 
> there are commands and utilities that already do approximately the same 
> thing, but I'm mainly doing this to learn to use the go/ast package and 
> everything. Let me give you a small example:
>
> - Let's say I have a package in my GOPATH that's named 'foo'
> - In this package there is another package 'bar', but this package bar has 
> grown a whole lot since the beginning of the project, and might as well be 
> a project on its own.
> - What I want is extract package 'bar' from 'foo' without having to go 
> through all other projects importing 'bar' to change import paths
> - The process for the command is to first move package 'bar' wherever I 
> tell it to move it and replace anything in previously existing package 
> 'foo/bar' with bindings, so any function's body is replaced with a call to 
> the function in the moved package, any type is transformed into an "alias" 
> of the moved package's corresponding type (TypeA = bar.TypeA), as well as 
> any constant or variable.
>
> The command is not finished yet but I'm running into a certain issue I 
> can't find a solution to:
>
> Whenever the command creates a binding for a given exported variable:
>
> var (
> Anything = 5.0
> )
>
> becomes
>
> var (
> Anything = bar.Anything
> )
>
> there's a risk that bar.Anything was originally changed during the 
> program's execution and according to the context. If that was the case, any 
> change to bar.Anything will not be applied in foo/bar.Anything, which 
> breaks the whole thing.
>
> Does anyone have an idea how to programmatically make it so that any 
> changes applied to bar.Anything is applied to foo/bar.Anything, as if they 
> really did share the same memory? Of course this would need to be totally 
> transparent to the user of the package.
>
> Maybe this is not possible but if you guys know anything, please tell me.
>
> Thanks in advance!
>
>
>

-- 
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/099b1934-f90f-492a-a620-04c51599a70e%40googlegroups.com.

[go-nuts] Re: Closed channel vs nil channel when writing

[clement auger]

sorry i can t find the added value i m looking for within those two 
publications. 

thanks for trying to help, it will be good pointers for future readers 
starting to learn go and reading those words.

Le lundi 2 septembre 2019 19:12:03 UTC+2, Jake Montgomery a écrit :
>
>
> On Monday, September 2, 2019 at 9:41:54 AM UTC-4, T L wrote:
>
>>
>> https://go101.org/article/channel.html
>>
>
> That is a great, and pretty detailed article. For quick reference I like 
> https://dave.cheney.net/2014/03/19/channel-axioms .
>

-- 
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/e578e7de-9dcb-4e0d-b92c-17001573f6cf%40googlegroups.com.

[go-nuts] Re: Closed channel vs nil channel when writing

[clement auger]

The compiler will produce the same result using an uninitialized channel 
variable (ie nil chan);
btw, the spec admits that a "nil channel" is a valid concept, several 
references can be found within it.

You might as well quote the specification rather than rephrasing, it is way 
shorter and efficient.

https://golang.org/ref/spec#Send_statements
"A send on a nil channel blocks forever. "

Le dimanche 1 septembre 2019 19:55:13 UTC+2, Albert Tedja a écrit :
>
> No such thing as a 'nil channel'. You are merely setting a variable to 
> nil, regardless what the previous content is.
>
> It's just that Go allows you to receive from a nil variable if that 
> variable's type is a channel, in which case it blocks forever.
>
>
>
> On Sunday, September 1, 2019 at 9:03:58 AM UTC-7, clement auger wrote:
>>
>> hi,
>>
>> I am looking for further details and explanations about the various 
>> behaviors
>> associated with closed Vs nil channels.
>>
>> I already read 
>> https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel
>> and other publications such as 
>>
>> https://medium.com/justforfunc/why-are-there-nil-channels-in-go-9877cc0b2308 
>> (for example)
>>
>> They repeat the explanation of the behaviors the programmer will have to 
>> deal with, 
>> however they don't really explain the internal, nor the reasons of the 
>> differences
>> found with this example https://play.golang.org/p/4LuZ32gzWbu when 
>> closing or niling the channel
>>
>> I wonder under which case it is useful to panic on write, Vs branching to 
>> a default case within a select.
>> Said differently what is the advantage of a panic Vs a syntax like ok := 
>> mychan <- myval; if !ok { return "not wrote" }
>>
>> This happened while reading at T.L. in 
>> https://groups.google.com/forum/#!topic/golang-nuts/lEKehHH7kZY
>>
>> *Yes, there are ways to handle the problem of uncertain number of 
>> senders, but there are no simple ways.*
>> *A mechanism must be designed to avoid any sender writing to a closed 
>> channel.*
>>
>> thanks for anyone able to provide some details.
>>
>

-- 
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/4f6709af-1d6c-40b2-b008-b0dad4ff7db3%40googlegroups.com.

[go-nuts] Closed channel vs nil channel when writing

[clement auger]

hi,

I am looking for further details and explanations about the various 
behaviors
associated with closed Vs nil channels.

I already read 
https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel
and other publications such as 
https://medium.com/justforfunc/why-are-there-nil-channels-in-go-9877cc0b2308 
(for example)

They repeat the explanation of the behaviors the programmer will have to 
deal with, 
however they don't really explain the internal, nor the reasons of the 
differences
found with this example https://play.golang.org/p/4LuZ32gzWbu when closing 
or niling the channel

I wonder under which case it is useful to panic on write, Vs branching to a 
default case within a select.
Said differently what is the advantage of a panic Vs a syntax like ok := 
mychan <- myval; if !ok { return "not wrote" }

This happened while reading at T.L. in 
https://groups.google.com/forum/#!topic/golang-nuts/lEKehHH7kZY

*Yes, there are ways to handle the problem of uncertain number of senders, 
but there are no simple ways.*
*A mechanism must be designed to avoid any sender writing to a closed 
channel.*

thanks for anyone able to provide some details.

-- 
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/5a8659a9-872a-495e-aa8b-33329c12694c%40googlegroups.com.

Re: [go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[clement auger]

remains the ugly code of tangled loop, routines and logic i saw and dealt 
with in the past... 

the link is *kind* *of* similar, thanks for sharing it.


Le mercredi 7 août 2019 00:16:34 UTC+2, Robert Engels a écrit :
>
> I was trying to make the point that even in languages where functional is 
> a first class citizen it can be difficult to read/maintain. What was lost 
> there is I should of started with just print the lines that have error - 
> this is trivial to accomplish functionally. Add in what is a trivial change 
> in an imperative style and the functional code gets very ugly. 
>
> Trying to do functional in Go with your proposed syntax would be very 
> difficult to maintain imo. 
>
> You might find this interesting https://github.com/robpike/filter
>
> On Aug 6, 2019, at 4:54 PM, clement auger  > wrote:
>
> each tools does not solve all problems with the same qualities.
>
> why take such example of sequential processing problem to try to solve it 
> using parallel / unordered processing ?
> it is same as shooting both your legs then trying to run a marathon
>
> the question worth to be asked twice as the go language is not 
> monoparadigm, unlike some pure players.
>
>
> Le mardi 6 août 2019 14:47:15 UTC+2, Robert Engels a écrit :
>>
>> It’s the verbosity of the syntax.  I’ll admit I’m not a fan of functional 
>> programming but the cases where it seems appropriate is where the syntax 
>> and chaining is so simple and straightforward as to be easier to read than 
>> an OO or imperative style.
>>
>> Try using your library to write a purely functional routine to scan lines 
>> of a file and when contains ‘error’ print out the 3 lines before and the 3 
>> lines after. (Thanks Mario Fusco). See if the code is readable by a non 
>> author. 
>>
>> Generics might improve things here but I doubt it (should help type 
>> safety) I think a lambda syntax is required for trivial transformations in 
>> order to make the streams readable. 
>>
>>
>>
>> On Aug 6, 2019, at 3:37 AM, clement auger  wrote:
>>
>> Hi Robert, 
>>
>> can you kindly elaborate please ? Are you criticizing the resulting api 
>> or its internal writing ? 
>>
>> If you were meaning the lack of comments, tests etc. yes i agree (who 
>> would not?), 
>> but then, I think I can only answer that this is only a matter of 
>> additional work hours.
>>
>> If this is the resulting overall api and its impact on the manners the 
>> programmer will implement solutions, 
>> i m interested to understand better.
>>
>> thank you.
>>
>> PS: to avoid a double post, I take advantage of this answer to thank 
>> others for their encouragements.
>>
>> Le dimanche 4 août 2019 16:56:20 UTC+2, Robert Engels a écrit :
>>>
>>> Would honestly want to maintain somebody else’s code that was written in 
>>> this style?  I wouldn’t. 
>>>
>>> On Aug 4, 2019, at 9:13 AM, clement auger  wrote:
>>>
>>> You tell me.
>>>
>>>
>>> https://github.com/clementauger/sta
>>>
>>>
>>> sta - stream async 
>>>
>>> Implements responsive data stream pipeline.
>>>
>>> It is a reasearch and concept project not to be used in production.
>>> <https://github.com/clementauger/sta#install>Install go get -u 
>>> github.com/clementauger/sta <https://github.com/clementauger/sta#doc>Doc 
>>> godoc.org/github.com/clementauger/sta 
>>> <https://github.com/clementauger/sta#example>Example 
>>>
>>> most simple.
>>>
>>> sta.Map([]string{"a", "b", "c"}).
>>> Map(strings.ToUpper).
>>> Sink(fmt.Println)
>>>
>>> This example demonstrate the implementation of a pipeline that bulks by 
>>> slices of strings of length 4. It declares two parallel workers to change 
>>> the strings cases. It outputs resulting values to stdout.
>>>
>>> sta.Map([]string{"a","b"}).
>>>   Map(sta.Accumulate(make([]string, 4), time.Second)).
>>>   Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
>>>   Sink(fmt.Println)
>>>
>>> <https://github.com/clementauger/sta#rationale>Rationale 
>>> <https://github.com/clementauger/sta#introduction>Introduction 
>>>
>>> sta takes full advantage of the CSP channel based go capabilities to 
>>> provide a simple implementation to compose, implement and refactor 
>>> responsive data stream pipeline.
>&

Re: [go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[clement auger]

each tools does not solve all problems with the same qualities.

why take such example of sequential processing problem to try to solve it 
using parallel / unordered processing ?
it is same as shooting both your legs then trying to run a marathon

the question worth to be asked twice as the go language is not 
monoparadigm, unlike some pure players.


Le mardi 6 août 2019 14:47:15 UTC+2, Robert Engels a écrit :
>
> It’s the verbosity of the syntax.  I’ll admit I’m not a fan of functional 
> programming but the cases where it seems appropriate is where the syntax 
> and chaining is so simple and straightforward as to be easier to read than 
> an OO or imperative style.
>
> Try using your library to write a purely functional routine to scan lines 
> of a file and when contains ‘error’ print out the 3 lines before and the 3 
> lines after. (Thanks Mario Fusco). See if the code is readable by a non 
> author. 
>
> Generics might improve things here but I doubt it (should help type 
> safety) I think a lambda syntax is required for trivial transformations in 
> order to make the streams readable. 
>
>
>
> On Aug 6, 2019, at 3:37 AM, clement auger  > wrote:
>
> Hi Robert, 
>
> can you kindly elaborate please ? Are you criticizing the resulting api or 
> its internal writing ? 
>
> If you were meaning the lack of comments, tests etc. yes i agree (who 
> would not?), 
> but then, I think I can only answer that this is only a matter of 
> additional work hours.
>
> If this is the resulting overall api and its impact on the manners the 
> programmer will implement solutions, 
> i m interested to understand better.
>
> thank you.
>
> PS: to avoid a double post, I take advantage of this answer to thank 
> others for their encouragements.
>
> Le dimanche 4 août 2019 16:56:20 UTC+2, Robert Engels a écrit :
>>
>> Would honestly want to maintain somebody else’s code that was written in 
>> this style?  I wouldn’t. 
>>
>> On Aug 4, 2019, at 9:13 AM, clement auger  wrote:
>>
>> You tell me.
>>
>>
>> https://github.com/clementauger/sta
>>
>>
>> sta - stream async 
>>
>> Implements responsive data stream pipeline.
>>
>> It is a reasearch and concept project not to be used in production.
>> <https://github.com/clementauger/sta#install>Install go get -u 
>> github.com/clementauger/sta <https://github.com/clementauger/sta#doc>Doc 
>> godoc.org/github.com/clementauger/sta 
>> <https://github.com/clementauger/sta#example>Example 
>>
>> most simple.
>>
>> sta.Map([]string{"a", "b", "c"}).
>>  Map(strings.ToUpper).
>>  Sink(fmt.Println)
>>
>> This example demonstrate the implementation of a pipeline that bulks by 
>> slices of strings of length 4. It declares two parallel workers to change 
>> the strings cases. It outputs resulting values to stdout.
>>
>> sta.Map([]string{"a","b"}).
>>   Map(sta.Accumulate(make([]string, 4), time.Second)).
>>   Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
>>   Sink(fmt.Println)
>>
>> <https://github.com/clementauger/sta#rationale>Rationale 
>> <https://github.com/clementauger/sta#introduction>Introduction 
>>
>> sta takes full advantage of the CSP channel based go capabilities to 
>> provide a simple implementation to compose, implement and refactor 
>> responsive data stream pipeline.
>>
>> A data stream pipeline is said to be responsive when it is able to react 
>> with its downstream at any point in time in response to a variation of its 
>> input.
>>
>> An implementation is said to be simple to compose, implement and refactor 
>> a data stream pipeline if its overall result expresses the solution with 
>> less lines of code, easier understanding, improved rewriting capabilities 
>> and testing experience.
>>
>> Does this attempt reaches its goal ? yes and no...
>> <https://github.com/clementauger/sta#concepts>Concepts 
>>
>> https://blog.golang.org/pipelines
>> <https://github.com/clementauger/sta#usage>Usage 
>>
>> sta exposes a Map function, to create stream instances.
>>
>>   s := sta.Map(src)
>>
>> src is a value that can take a plurality of data kind.
>>
>>   s := sta.Map([]string{"a","b"})
>>   s = sta.Map([]int{1,2})
>>   s = sta.Map(make(chan string))
>>   s = sta.Map(func(output chan string){ output<-"hello world!" })
>>
>> sta.Map reads the given input in a separate routine and manages for it

Re: [go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[clement auger]

Hi Robert, 

can you kindly elaborate please ? Are you criticizing the resulting api or 
its internal writing ? 

If you were meaning the lack of comments, tests etc. yes i agree (who would 
not?), 
but then, I think I can only answer that this is only a matter of 
additional work hours.

If this is the resulting overall api and its impact on the manners the 
programmer will implement solutions, 
i m interested to understand better.

thank you.

PS: to avoid a double post, I take advantage of this answer to thank others 
for their encouragements.

Le dimanche 4 août 2019 16:56:20 UTC+2, Robert Engels a écrit :
>
> Would honestly want to maintain somebody else’s code that was written in 
> this style?  I wouldn’t. 
>
> On Aug 4, 2019, at 9:13 AM, clement auger  > wrote:
>
> You tell me.
>
>
> https://github.com/clementauger/sta
>
>
> sta - stream async 
>
> Implements responsive data stream pipeline.
>
> It is a reasearch and concept project not to be used in production.
> <https://github.com/clementauger/sta#install>Install go get -u 
> github.com/clementauger/sta <https://github.com/clementauger/sta#doc>Doc 
> godoc.org/github.com/clementauger/sta 
> <https://github.com/clementauger/sta#example>Example 
>
> most simple.
>
> sta.Map([]string{"a", "b", "c"}).
>   Map(strings.ToUpper).
>   Sink(fmt.Println)
>
> This example demonstrate the implementation of a pipeline that bulks by 
> slices of strings of length 4. It declares two parallel workers to change 
> the strings cases. It outputs resulting values to stdout.
>
> sta.Map([]string{"a","b"}).
>   Map(sta.Accumulate(make([]string, 4), time.Second)).
>   Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
>   Sink(fmt.Println)
>
> <https://github.com/clementauger/sta#rationale>Rationale 
> <https://github.com/clementauger/sta#introduction>Introduction 
>
> sta takes full advantage of the CSP channel based go capabilities to 
> provide a simple implementation to compose, implement and refactor 
> responsive data stream pipeline.
>
> A data stream pipeline is said to be responsive when it is able to react 
> with its downstream at any point in time in response to a variation of its 
> input.
>
> An implementation is said to be simple to compose, implement and refactor 
> a data stream pipeline if its overall result expresses the solution with 
> less lines of code, easier understanding, improved rewriting capabilities 
> and testing experience.
>
> Does this attempt reaches its goal ? yes and no...
> <https://github.com/clementauger/sta#concepts>Concepts 
>
> https://blog.golang.org/pipelines
> <https://github.com/clementauger/sta#usage>Usage 
>
> sta exposes a Map function, to create stream instances.
>
>   s := sta.Map(src)
>
> src is a value that can take a plurality of data kind.
>
>   s := sta.Map([]string{"a","b"})
>   s = sta.Map([]int{1,2})
>   s = sta.Map(make(chan string))
>   s = sta.Map(func(output chan string){ output<-"hello world!" })
>
> sta.Map reads the given input in a separate routine and manages for it 
> the required output communication channels.
>
> The generated output channels are given to downstream transforms of the 
> stream.
>
>   s := sta.Map([]string{"a","b"}).
> Map(func(v string) int { return len(v)})
>
> stream.Map transforms a given input to an output, in a separate routine. 
> It generates the required communication channels and connects them with the 
> upstream and downstream automatically.
>
> To handle fine control of the data flow, stream.Map can handle functions 
> that receives the upstream channel. Those functions must return a processor 
> function that implements the loop over the upstream channel, and an output 
> channel they are writing. The output channel is closed after that the 
> processor function has terminated.
>
>   s := sta.Map([]string{"a","b"}).
> Map(func(input chan string) (func()error, chan int) {
>   output := make(chan int)
>   processor := func()error {
> for v := range input {
>   output<-len(v)
> }
>   }
>   return processor, output
> })
>
> To execute the pipeline, the developer must call for the stream.Sink 
> function. stream.Sink is realy just like stream.Map except that it closes 
> the stream by executing it.
>
>   err := sta.Map([]string{"a","b"}).
> Map(strings.ToUpper).
> Sink(sta.DevNull)
>
> stream.Sink writes the destination in a separate r

[go-nuts] pushing too far reflect usage ? another attempts to pipline based processing

[clement auger]

You tell me.


https://github.com/clementauger/sta


sta - stream async 

Implements responsive data stream pipeline.

It is a reasearch and concept project not to be used in production.
Install go get -u 
github.com/clementauger/sta Doc 
godoc.org/github.com/clementauger/sta 
Example 

most simple.

sta.Map([]string{"a", "b", "c"}).
Map(strings.ToUpper).
Sink(fmt.Println)

This example demonstrate the implementation of a pipeline that bulks by 
slices of strings of length 4. It declares two parallel workers to change 
the strings cases. It outputs resulting values to stdout.

sta.Map([]string{"a","b"}).
  Map(sta.Accumulate(make([]string, 4), time.Second)).
  Map(sta.Each(strings.toUpper), sta.Each(strings.toUpper)).
  Sink(fmt.Println)

Rationale 
Introduction 

sta takes full advantage of the CSP channel based go capabilities to 
provide a simple implementation to compose, implement and refactor 
responsive data stream pipeline.

A data stream pipeline is said to be responsive when it is able to react 
with its downstream at any point in time in response to a variation of its 
input.

An implementation is said to be simple to compose, implement and refactor a 
data stream pipeline if its overall result expresses the solution with less 
lines of code, easier understanding, improved rewriting capabilities and 
testing experience.

Does this attempt reaches its goal ? yes and no...
Concepts 

https://blog.golang.org/pipelines
Usage 

sta exposes a Map function, to create stream instances.

  s := sta.Map(src)

src is a value that can take a plurality of data kind.

  s := sta.Map([]string{"a","b"})
  s = sta.Map([]int{1,2})
  s = sta.Map(make(chan string))
  s = sta.Map(func(output chan string){ output<-"hello world!" })

sta.Map reads the given input in a separate routine and manages for it the 
required output communication channels.

The generated output channels are given to downstream transforms of the 
stream.

  s := sta.Map([]string{"a","b"}).
Map(func(v string) int { return len(v)})

stream.Map transforms a given input to an output, in a separate routine. It 
generates the required communication channels and connects them with the 
upstream and downstream automatically.

To handle fine control of the data flow, stream.Map can handle functions 
that receives the upstream channel. Those functions must return a processor 
function that implements the loop over the upstream channel, and an output 
channel they are writing. The output channel is closed after that the 
processor function has terminated.

  s := sta.Map([]string{"a","b"}).
Map(func(input chan string) (func()error, chan int) {
  output := make(chan int)
  processor := func()error {
for v := range input {
  output<-len(v)
}
  }
  return processor, output
})

To execute the pipeline, the developer must call for the stream.Sink 
function. stream.Sink is realy just like stream.Map except that it closes 
the stream by executing it.

  err := sta.Map([]string{"a","b"}).
Map(strings.ToUpper).
Sink(sta.DevNull)

stream.Sink writes the destination in a separate routine.

The given destination value can be of kinds such as slice pointers, 
channels or functions.

  outSlice := []string{}
  sta.Map([]string{"a","b"}).Sink()

  outChan := make(chan string)
  sta.Map([]string{"a","b"}).Sink(outChan)

  outFn := func(v string){}
  sta.Map([]string{"a","b"}).Sink(outFn)

  outChanFn := func(v chan string) (func() error) { return func()error{return 
nil}}
  sta.Map([]string{"a","b"}).Sink(outChanFn)

Merge 

To merge a source, simply add more sources to the stream. Each source runs 
into their own routine.

It results in a simple merge operation of the output values.

Sources can have different kind, but they should converge to a compatible 
output type.

  sta.Map(
[]string{"a","b"},
[]string{"c","d"},
func(output chan string) {
  output<-"e"
  output<-"f"
},
func(output chan string) {
  output<-"e"
  output<-"f"
},
  )

Parallel 

To implement parallel transforms, simply add more transform to the targeted 
step. Each added transform runs into its own routine.

The stream will implement automatic distribution of input data and inline 
output data to downstream.

sta.Map([]string{"a","b"}).
  Map(strings.ToUpper, strings.ToUpper, strings.ToUpper)

sta.Map([]string{"a","b"}).
  Map(sta.Workers(3, strings.ToUpper)...)

sta.Map([]string{"a","b"}).
  Map(sta.Workers(3, func() interface{} {
// 

[go-nuts] Re: prevent alteration of binaries once distributed in the wild?

[clement auger]

thanks to everyone for sharing its thoughts about this question.

it confirms what i read elsewhere.

this app is to install on the end user computer, 
and there is no central authority required to use its
service.Unlike the game Michael Jones is working on,
where somehow the user must to connect some server.

The only reason i have to introduce a central authority,
or a network of peer validation (a way i have thought about to prevent a 
simple MITM), 
is for licensing concerns.

Giving the control of the data to the end user is part of the value added 
of the product,
so hosting it on a managed remote platform is not an option.

I was hoping some sort of cross platform one-for-all solution.
Ideally, quick to setup (...).
Having to rely on package managers to install it is something i have to 
research.

A quick search reveals projects to implement automatic patching.
I did not think to search about this before today.
It does not look like fully automated yet, but they definitely follow the 
path.

Alternatively, an obfuscation tool exists here 
https://github.com/unixpickle/gobfuscate
I ll give it a try but if anyone ever has tested it
i would very much appreciate a feedback.

Is it still true that -w might break things when using the reflection 
package ?
https://stackoverflow.com/a/20928030

On a broader and less personal perspective i also asked because i m 
freaking out of all those governments 
wanting to install backdoor everywhere and feel completely defenseless to 
what they will implement soon. 
Because they will do. 
But this is not a programming topic so i will not expand.

-- 
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/a513dbb4-d4d2-4169-b49c-5743e5ee8337%40googlegroups.com.

[go-nuts] prevent alteration of binaries once distributed in the wild?

[clement auger]

Hi,

I m looking for a technique to prevent binary alteration once distributed 
in the wild.

I have no clue what i m asking for.

I was imagining a solution where a signature is prepended to the binary and 
checked during the startup sequence.

However i do understand (well ... i imagine it) the chicken and egg problem 
behind this question (no way to sign a binary that will gets its signature 
inserted right after its signature was computed)

Is there anything possible ?

Is it something i should be worried of, to start with ? (independently of 
the interest that altering such binary might raises, i d prefer a strictly 
technical analysis)

thanks for feedbacks.

-- 
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/194e2e4f-e41b-4c23-b241-f8fe1f5da154%40googlegroups.com.