version.hpp not updated

Still says the MINOR_VERSION is 5. It seems that updating this should be part of the build script somehow ...
  /** Major version number for Stan package. */
  const std::string MAJOR_VERSION = "2";

  /** Minor version number for Stan package. */
  const std::string MINOR_VERSION = "5";

  /** Patch version for Stan package. */
  const std::string PATCH_VERSION = "0";

My bad, not updated in submodule


JS wrap

Hi, I really miss this feature which allows to wrap selected code for example in try/catch. I saw you can do this only with HTML using Emmet: Wrap...
Thank you!

Tracked by https://github.com/Microsoft/TypeScript/issues/18458
You can use snippets to approximate this today (see $TM_SELECTED_TEXT)


Pointnet2_ops problem

there is an error while trying to install pointnet2_ops with python3.7 as you used
nvcc fatal   : Unsupported gpu architecture 'compute_37'
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\torch\utils\cpp_extension.py", line 1539, in _run_ninja_build
env=env)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\subprocess.py", line 512, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "setup.py", line 38, in
include_package_data=True,
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools_init_.py", line 144, in setup
return distutils.core.setup(**attrs)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\core.py", line 148, in setup
dist.run_commands()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\dist.py", line 966, in run_commands
self.run_command(cmd)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools\command\install.py", line 67, in run
self.do_egg_install()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools\command\install.py", line 109, in do_egg_install
self.run_command('bdist_egg')
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools\command\bdist_egg.py", line 173, in run
cmd = self.call_command('install_lib', warn_dir=0)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools\command\bdist_egg.py", line 159, in call_command
self.run_command(cmdname)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools\command\install_lib.py", line 11, in run
self.build()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\command\install_lib.py", line 107, in build
self.run_command('build_ext')
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\dist.py", line 985, in run_command
cmd_obj.run()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools\command\build_ext.py", line 87, in run
_build_ext.run(self)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\command\build_ext.py", line 340, in run
self.build_extensions()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\torch\utils\cpp_extension.py", line 670, in build_extensions
build_ext.build_extensions(self)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\command\build_ext.py", line 449, in build_extensions
self._build_extensions_serial()
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\command\build_ext.py", line 474, in _build_extensions_serial
self.build_extension(ext)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\setuptools\command\build_ext.py", line 208, in build_extension
_build_ext.build_extension(self, ext)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\distutils\command\build_ext.py", line 534, in build_extension
depends=ext.depends)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\torch\utils\cpp_extension.py", line 652, in win_wrap_ninja_compile
with_cuda=with_cuda)
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\torch\utils\cpp_extension.py", line 1255, in _write_ninja_file_and_compile_objects
error_prefix='Error compiling objects for extension')
File "C:\Users\Husse\AppData\Local\Programs\Python\Python37\lib\site-packages\torch\utils\cpp_extension.py", line 1555, in _run_ninja_build
raise RuntimeError(message) from e
RuntimeError: Error compiling objects for extension
i tried to used python3.9 before and it worked but i had problem with chamfer_3D
installation didn't show any error but trying to run train.py showed an error that the module chamfer_3D could not be found

well finally, it worked with python3.7 when i removed 3.7+PTX; from TORCH_CUDA_ARCH_LIST in pointnet2_ops setup.py (line 19)


proposal: cmd/go: automatically detect GOPATH

Setting up a workspace/GOPATH is one of the big hurdles for new Go users.
This proposal is to make the GOPATH environment variable optional, and to have the go tool detect the GOPATH root on invocation. It would to this by walking up the tree from the cwd to find a directory named src, and setting GOPATH to the parent of that directory.
For new users, the getting started experience is something like:
mkdir -p src/github.com/user/hello
cd src/github.com/user/hello
vim hello.go
go install
hello

or to install something else:
mkdir src
cd src
go get github.com/docker/docker

Thoughts?

/cc @jbuberel  who was talking about this this morning.

@adg thanks for raising this proposal. I thought it was going to be more along the lines of "lets have a default GOPATH value (and it might be $HOME)"

mkdir -p src/github.com/user/hello
cd src/github.com/user/hello
vim hello.go
go install
hello

I like this, but I think there are still a number of edge case that have to be explained en rote.
q. why do I need to make a sub directory, can't go just work in my current directory ?
a. no, not really, Go works with packages, and packages are a directory
q. oh, ok, well I put my code in src/hello.go and it didn't work
a. ahh, well, src is special, you cannot put code directly in src/
q. ok, so I put my code in gocode/hello.go and it didn't work, you told me src/ was special so I didn't use it
a. err, right, sorry, you need to use src/, but you can't put any code in that, try src/hello/hello.go
q. ok, thanks for helping, that worked, but I have a question, why do I need all these directories, shouldn't Go be able to figure this out ?
a. <insert long technical explantation about package names being derived from import paths and how src/ would name no import path so technically not be importable into other package, not that that it matters 'cos its a main package>
q. what's a package, i just wanted to try helloworld.go
This is taken pretty much verbatim from my experiences having to justify the $PROJECT/src directory in gb.

I'd like to suggest that any automatic strategy to compute GOPATH should work anywhere within $GOPATH, not just within $GOPATH/src.  E.g., it should at least also work within $GOPATH/bin and $GOPATH/pkg.
Easy variation of the proposed scheme is instead of looking for a parent directory named "src" (and then using its parent as GOPATH), look for a parent directory with a "src" child directory (and using the parent itself as GOPATH).
Another option would be to add a new identifying file within the root directory.  E.g., Bazel uses an empty file named "WORKSPACE" (see "Getting Started with Bazel" and Chromium's GN uses a file named ".gn" with config settings (see "What you need for a minimal GN build").

I think we don't need to support $GOPATH/bin and $GOPATH/pkg,
because I can't think of a reason why I'd in one of those directory
and still use go build/install/test. Just handle the common case looks
good to me.
I also don't like introducing a new file to mark GOPATH.

@davecheney I think at some point people need to learn about packages. I don't think we should design our entire build process around the very first new user experience. Can you suggest a way of avoiding this conversation that doesn't throw out everything we already have? (My gut reaction is "just tell them to put it in "src/hello" in the first place.")
@mdempsky I concur with @minux - I have no idea why you would care about resolving $GOPATH inside pkg or bin. I never change to those directories, ever. I also don't see the purpose in adding special files, when we already have a special directory (src).
Another consideration for this proposal is that it will theoretically break anyone that already has packages whose import paths have a src path component.

:+1: This change makes sense. I don't see what a default $GOPATH (for example at $HOME) would solve in terms of making it easier to get started with Go. I think if a user knows about $HOME (it's significance) then he is proficient enough to setup a correct $GOPATH.

@mdempsky I think the idea of "GOPATH is the parent of a directory called src/" works well.
@adg

I think at some point people need to learn about packages.

Agreed.

I don't think we should design our entire build process around the very first new user experience.

I'll have to disagree with you to some degree there :smile:

Can you suggest a way of avoiding this conversation that doesn't throw out everything we already have? (My gut reaction is "just tell them to put it in "src/hello" in the first place.")

I think I probably conflated a number of things in my response. From my experience there are several common pain points for newcomers when they see a path like src/github.com/user/hello

Why do I have to setup GOPATH, why can't I just put my stuff anywhere I want (or more likely where I put it in $INSERT_PREVIOUS_LANGUAGE). To that, I agree with you, the answers is "Because reasons".
The second is why do they have to put things in a subdirectory of a subdirectory src/ ? Again, it's probably better to stick with "reasons".
The third is the confusion that putting a github'ish url in the path. We've seen lots of users who think they have to push to github to compile.

Maybe this is just a matter of introducing the terms in order. Something like
There are two pieces of information you need to know to write Go code.  A GOPATH workspaces is any directory that contains the following three directories src/, bin/, and pkg/. You can create one like this
mkdir -p gocode/{src,bin,pkg}

So, gocode is your workspace, your GOPATH. gocode/src is where you will put your Go packages (we'll get to that in a second), gocode/bin is where the compiler will place any programs you compile, and gocode/pkg is the location that the compiler will cache files for later reuse to speed up compilation.
As mentioned above, all the Go code you write must be arranged into packages. What is a package ? A package is just a directory. The name of the directory must match the name of the package declaration that every file in that directory shares, that's why we call them packages.
Putting these two pieces of knowledge together, if you want to write a program called hello, it needs to be in the hello package, and knowing that packages need to live inside your workspaces' src/ directory, the path to this package must be gocode/src/hello
This explanation obviously trades off some degree of accuracy to avoid getting bogged down in the details, please don't beat me up for this.

What about go init [-path] where path defaults to $HOME/gopath and be done with it?
That could initialize the path, create an directory example too with a minimal main + package and fill this with some dummy content working on all major systems. It then also shows what it did (e.g. go get -v -x example/..., where it puts the stuff and what it actually is (e.g. a minimal binary, an example package, etc.)
When the $GOPATH is missing, suggest setting $GOPATH  or calling go init to the user, if he doesn't know what we are talking about.
(Linux- )Distributions could then also easily integrate go init, if their policy needs defaults.
(Appropriate defaults for e.g. Windows are left out for the moment but can be easily added)

Is there a reason why we can't just build our default gopath in $GOROOT? Just add a $GOROOT/usr/$USER directory which is populated with it's own /bin, /src, /pkg and auto generated by the go tool.
Its one thing to have the developer explicitly state where they specify $GOPATH resides on their system, its another to allow go to automatically dig around for one.

I think the original proposal is fine for those who understand package and workspace structure but I don't believe it to be helpful to new Go users as was suggested. The problem is that it's very likely that new Go users will be creating test directories within existing directory trees that contain code of differently languages -- and src is likely to be a directory that exists all over within that same tree.

The go tool doesn't care if you have scripts/files written by other programming languages in ols the directory it found a set of *.go files. It only mandates that there is only one go package defined per nested directory within "$GOPATH/src".
I "get" what @adg is saying. Ideally when you use the command go install   or go build, you have fed the tool a path (which may be either explicitly defined or implicitly deduced that $PWD is the intended target). Given that the tool already knows where the package you want to build resides, all it has to do is hop up into sequential parental directories until it lands in a parent directory called "src". Which then the go tool can deduce that ../src is either a gopath that is already known to the go tool, or it's a base directory where the go tool can construct a new gopath if it is found that one doesn't already exist at said location.
I mean it definitely could work. It's just a really hooky programming environment convention if you ask me. It doesn't seem like it would always play nicely with Unix's file system security model either. (you develop your pkg in /usr/src, go installs executable in /usr/bin, which could bring about potential issues like system util name conflicts, or confused package managers, etc etc.
Personally, I think @adg's proposal makes the go tool far too "magic wand"-ey, for the amount of convenience the language would gain from an implementation of his proposed extension.

My concern wasn't so much that the code of other languages would be an issue; only that src is a common directory name and I figured there would be some potential conflicts in just assuming that you were working with a Go package's src directory when in fact it could be something entirely different. You gave a good example, @mortdeus -- /usr/src could be a conflicting directory if they happened to be working out of that directory. It's not likely but it could happen.

Also if we did do this we would have to adopt a policy that each gopath would be isolated from each other's view unless GOPATH has been explicitly set. The reason being the fact that the go tool can't resolve a lookup path precedence ambiguity with out a directorial cue from the user pertaining to their personal preference.

What if go could configure workspace configurations?
$ go create workspace /home/tyler/myworkspace

Then from anywhere you could do something like:
$ go myworkspace build

Maybe allow for a default or an active workspace:
$ go active workspace myworkspace

With an active workspace set you could simply do:
$ go build

The workspace name would be derived from the path passed at creation and could be referenced as simply.
To facilitate this, you’d need to allow for a GOCONF environment variable to point to a location where a simple config file (containing workspace names and GOPATHs for each) could be written/read by the tool and at that point perhaps the complexity of the situation is just the same; Thoughts?

I was also thinking about the idea for a go "workspace" project container object that essentially gives users one last degree of expressing package addressability. You wouldn't have to explicitly create, set, manage, and/or mess with them in any explicit way really.
Rather the workspace mechanism would work by walking up the tree until we find ourselves inside of a "src" directory. Once there we "cd .." into the parent base dir where we ideally want to set up the gopath we associate with the pkg were building. Since that parent base directory must have an identifier, we can use it to declare a workspace context for that GOPATH.
Syntactically the "workspace" identifier is treated just like a top level domain in all its usage contexts. For example if we wanted to call an executable that is in a specific $GOPATH/bin, we can just call go tool workspace.execname. Which is useful considering the fact that that GOPATH/bin might not be appended to the system path and would otherwise require us to call the exec using its full canonical file path identifier.
In the context of it's import path string, it would be just a top level domain.
import "workspace.gorepo.com/path/2/mypkg"
Then in $GOROOT, go get will fetch and install to $GOROOT/users/$USER/$workspace/src/path/2/mypkg
In the case that the top level domain is attachted to say github.com. We can just use the top level domain syntax to allude to a sub branch and/or tagged commit. And just create the workspace context name by appending the pkgname in front of the top level domain.
So lets say we have import "v2.github.com/mortdeus/mypkg", the go get tool will see the v2, then the github.com, then the user name, and then the pkgname. Go get will resolve this to the directory $GOROOT/users/mortdeus/mypkg.v2/src/github.com/mortdeus/mypkg
Then if we have a few executables called say mypkg/server, mypkg/client, mypkg/shell, mypkg/main
we can call the executables like 'go tool mypkg.server', 'go tool mypkg.shell', 'go tool mypkg.main' (or just 'go tool mypkg' in the special case of mypkg.main).
Idk its just an idea.

oh and in the case where we have a set of workspace ambiguity where we have say $GOROOT/users/{me | you}/gopkg/src/github.com/{my|your}/gopkg
Obviously we have a conflict here regarding which "gopkg" executables are tied to the globally resolved generic "gopkg" workspace identifier as far as the go tool is concerned. The best way I can think of resolving this is to have a $GOROOT/users/mortdeus/bin that links to the workspace's executables we prefer to be called in the case of a naming conflict.

Another consideration for this proposal is that it will theoretically break anyone that already has packages whose import paths have a src path component.

A solution could be to say that the GOPATH is the parent of the top (instead of the bottom) src directory in the current directory. So, for example, when running go install from /home/user/src/github.com/project/src/package1, GOPATH would be set to /home/user.
I think it is more unlikely to break something this way and with the right wording it is not more complicated (I am assuming the fraction of users with GOPATHs inside src directories is neglegible). For new users, I think the most important point is showing a sensible error message when trying to build a package outside of a GOPATH (or with this proposal, outside of a src directory).

shouldn't it be something like $HOME/src/go instead ? src/ is a very generic name and there is a decent chance someone will be using it for something else than golang

I like @adg's proposal at the beginning of this issue of determining the GOPATH from the current working directory if the environment variable is not set.
There are several other interesting ideas proposed here, like a default GOPATH and a go init subcommand, that are compatible with the original proposal. They could be done instead of or as well as automatically detecting the GOPATH. Are any of them arguments against determining the GOPATH from the current working directory? If they are complementary they can be considered separately. If they are arguments against @adg's original proposal, I think it would be helpful to frame them as such.

In my opinion auto-detecting GOPATH via src is too magical and can lead to unintended behaviour, specially since src is ubiquitous on developing environments.
As a multiple workspace and direnv user, I can vouch for a file .gopath generated via go init. It's unambiguous, most people are already familiar with the pattern thanks to git, and enables more extensibility as a potential source of metadata, like multiple paths, build flags, etc.

@adg's proposal would be a nice improvement to the tool chain. It doesn't change anything when GOPATH is already set, and when it's not, it simplifies the workflow. Many tools like git, hg or Node/npm already successfully implement a similar behaviour.

I really like the idea of auto-detecting GOPATH. I've been thinking about how to do this ever since I saw that @davecheney had done the equivalent in gb.
I'm not as sure about how. Finding src does seem to be the obvious choice, and it may work well. On the other hand, it may lead to wrong or confusing behavior if it found an unrelated src. At the least I think you'd need to say it's the highest-level src, so that if someone names their GitHub repo src and you're in /home/you/src/github.com/otherguy/src/pkg that uses GOPATH=/home/you.
Then there's the problem that any directory-based detection fails when you're outside the directory. You might be in $HOME or $HOME/bin and realize you need a command and run "go get that/command" and it fails because you're not in the src tree. That's annoying.
@davecheney's other points based on experience with gb are interesting too.
Counter-proposal, as suggested by Dave: If GOPATH is not set, it defaults to the user's home directory (aka $HOME on Unix, $USERPROFILE on Windows, $home on Plan 9).
The counter-proposal is not as flexible, but it's the suggested setting, it works outside the source tree, and it can't ever be confused by an inadvertently named parent directory.
I put the counter-proposal here mainly to play devil's advocate: if we're going to autodetect, we should make sure we are considering all the possible ways, not just one, and then pick the best.
As I go through the details, though, I'm starting to like default $HOME better than default magic search based on current directory.

@rsc thanks for your comments.
re: finding the wrong src directory in a hierarchy. I think this is quite
unlikely, to the point that the advice could be 'don't do that'. There are
some Go repos on github (not naming any names, but those may be children of
the alphabet group) that include a '/src/' directory in the checkout, but
they could be said to be in the former category and should be fixed.
re: not being able to do 'go $CMD' anywhere on the filesystem is quite a
limitation. In both this and the previous case gb punts on this by making
it clear you arrange your work into projects and decide which project you
are working on by being present inside that directory -- a model well
understood by most git/svn/hg users. As a backup there is a -R flag to
override the root of the project detection logic, analogous to -C in modern
versions of git.
With that said, the place where this will bite will be go get from
scratch, that is to say, the first user experience; install go; go get
$BIGPROJECT; confusing error message as there is no /src/ to be found on
the filesystem and the user was following some potted advice from a project
README, not our getting started documentation.
In the face of this, defaulting $GOPATH to $HOME would
a. solve all of the issues above
b. mean that in the average case users have to set zero environment
variables to use Go, a moderate win for posix users, and a substantial win
for Windows users.
And, as you say, if people don't like the default, all they have to do is
set $GOPATH, just as they have for the last 5 years.
On Sat, Oct 24, 2015 at 2:54 PM, Russ Cox<EMAIL_ADDRESS>wrote:

I really like the idea of auto-detecting GOPATH. I've been thinking about
how to do this ever since I saw that @davecheney
https://github.com/davecheney had done the equivalent in gb.
I'm not as sure about how. Finding src does seem to be the obvious
choice, and it may work well. On the other hand, it may lead to wrong or
confusing behavior if it found an unrelated src. At the least I think
you'd need to say it's the highest-level src, so that if someone names
their GitHub repo src and you're in /home/you/src/
github.com/otherguy/src/pkg that uses GOPATH=/home/you.
Then there's the problem that any directory-based detection fails when
you're outside the directory. You might be in $HOME or $HOME/bin and
realize you need a command and run "go get that/command" and it fails
because you're not in the src tree. That's annoying.
@davecheney https://github.com/davecheney's other points based on
experience with gb are interesting too.
Counter-proposal, as suggested by Dave: If GOPATH is not set, it defaults
to the user's home directory (aka $HOME on Unix, $USERPROFILE on Windows,
$home on Plan 9).
The counter-proposal is not as flexible, but it's the suggested setting,
it works outside the source tree, and it can't ever be confused by an
inadvertently named parent directory.
I put the counter-proposal here mainly to play devil's advocate: if we're
going to autodetect, we should make sure we are considering all the
possible ways, not just one, and then pick the best.
As I go through the details, though, I'm starting to like default $HOME
better than default magic search based on current directory.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/12488#issuecomment-150750387.

I'd argue that $HOME/src might be pretty common place to put source code by developers and crapping all over it by default doesn't sound like a great idea, even something like $HOME/src/go would make it much better

On 24 October 2015 at 14:54, Russ Cox<EMAIL_ADDRESS>wrote:

As I go through the details, though, I'm starting to like default $HOME
better than default magic search based on current directory.

Sounds good to me.
I note the concerns about "crapping all over a user's home directory." But
I think putting stuff in $HOME/src isn't too objectionable, especially
since we make directories that directly reflect where the source came from
("github.com/...", etc).
I can foresee objections to $HOME/pkg being created automatically, but
issue #4719 might solve that for us.
Is $HOME/bin a problem? Seems like the logical place to "go install"
commands to IMO.

@adg why not $HOME/src/go ? Much less chance to collide with anyone's workflow ( I know few people using src/{source}/{repo} as their layout ) and if for some reason you need to clear/remove your environment you just remove one dir instead of sifting thru anything else you might have in src

Because that would be change the way $GOPATH works.
The proposed change is to set a default GOPATH, not to change its
semantics.
On 13 November 2015 at 15:54, XANi<EMAIL_ADDRESS>wrote:

@adg https://github.com/adg why not $HOME/src/go ? Much less chance to
collide with anyone's workflow ( I know few people using
src/{source}/{repo} as their layout ) and if for some reason you need to
clear/remove your environment you just remove one dir instead of sifting
thru anything else you might have in src
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/12488#issuecomment-156321155.

Until #4719 (killing the "pkg" dir, turning it into a cache in a system-specific user cache location), I can't get excited about GOPATH=$HOME. I'd be happy with GOPATH=$HOME/gopath as @nightlyone proposed earlier. It has the advantage that when we say "in your go path", it has the double meaning of either $GOPATH or "$HOME/gopath".

We could always rename pkg to gopkg.out.

We could always rename pkg to gopkg.out.

It's still kinda a turd in $HOME, whatever it's called. (even if it starts with a dot, which I know is sacrilege)
I'd prefer to address #4719 before doing an automatic $GOPATH.

gopkg.out was a joke (reference to gopkg.in). We can't reasonably rename pkg/ today.
I agree that creating $HOME/pkg automatically is not ideal.
But $HOME/gopath seems clearly the wrong default too.
That seems to exclude a static default.
That still leaves the dynamic approach of walking up from the parent directory looking for a src/ element (or perhaps looking for a dir with a src/ subdir, so that the go command would work in the bin directory too). Thoughts there? @davecheney, you've offered somewhat balanced pros and cons for the automatic detection; overall do you think it is a good idea for GOPATH?

It certainly makes a lot of things work out of the box, with "autodetect" setting gopath is no longer needed for usage like "run tests on CI server" (where $HOME is /var/lib/jenkins and you do not want to litter that but keep per-job files to its workspace dir) and building newly downloaded app "just works" (if it have src dir created ofc) even if your "main" dir have some old versions of package

+1 on defaulting to $HOME if no $GOPATH is set. $HOME/pkg is ugly, but could be solved later.

I think recursing upwards and looking for a file, like .gopath or .go to determine the $GOPATH is the best bet. I personally use $HOME/src for other things, and would be annoyed if go started using it. Also, src is present in many unix systems, see https://www.freebsd.org/cgi/man.cgi?hier(7) and https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard.

Is this proposal about helping people who don't know/understand GOPATH workspaces be able to use Go? Or is it about making it more convenient for people who know it but deal with many systems, CI, etc.?

The former. Opting out of automatic detection is way, just set GOPATH.

On 11 Dec 2015, at 10:30, Dmitri Shuralyov<EMAIL_ADDRESS>wrote:
Is this proposal about helping people who don't know/understand GOPATH workspaces be able to use Go? Or is it about making it more convenient for people who know it but deal with many systems, CI, etc.?
—
Reply to this email directly or view it on GitHub.

Please don't pollute $HOME with a default $GOPATH. It's already very crowded. I'd go +1 for $HOME/whatever.
I mean in that case, the delinquent would see a $HOME/src as well? And a $HOME/bin???  Let's keep go where it belongs, in a neat module in it's own directory of some kind.
Couple of choices:

$HOME/gopath ( I have no problems with that )
$HOME/gohome
$HOME/godefault
$HOME/go (simple, yet elegant)
$HOME/goworkspace
$HOME/gouserspace
...

I am putting this proposal on hold.

The time has come to revisit this, I believe.

why not? GOPATH=$(pwd):$(pwd)/vendor:$(somedefault_butpleasenotinhome)
Just to move the conversation forward Node has both local packages to the project and a global install location. To be fair, I haven't had any issues prefixing go build with my goapth.

since nobody mentioned it already, linking the PYTHONPATH documentation here. By default, python uses _prefix_/lib/python_version_
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH

Another idea:

Add the option to mark gopath by a special file in the directory (.gopath for example)
Create a go path tool that checks if gopath is set, if not use said heuristics to find the probable directory and ask if this should be your gopath, if so, set the .gopath marker. After running always return/set correct gopath.
When running a tool that needs gopath, use go path tool to get gopath if it's missing.

Advantages:

Existing config doesn't change
New users will have a gopath setup, but can refuse
Heuristics can be applied
Systems without working environment variables for any reason can configure a persistent gopath

At some point I had something like this: https://gist.github.com/mem/21b0db6e6f672ba7c46cab457c34ae2b (I just rewrote and uploaded it for discussion purposes)
I share @bradfitz's view about setting GOPATH=$HOME, particularly because it tends to overwrite things I have purposefully put in ~/bin (and I don't like seeing the pkg dir there).
The one problem I have with this is that it doesn't do anything for this use case:
$ cd ~/random/dir
$ mkdir src/hello
$ edit src/hello/main.go
# edit here
$ go install hello
$ hello
-bash: hello: command not found

this happens because GOPATH gets set to ~random/dir, but nothing happens with PATH (nor should it). What happens now is that you have to start telling people where the binary ended up in. In this specific case, the alternative is to tell them to type bin/hello instead of just hello, but that doesn't feel like a solution.

I have a counterproposal:
When $GOPATH is unset, behave like "git clone" or "svn checkout" - place the requested package in the current directory. Place the dependencies in a "vendor/" subdirectory under the newly-created directory.
Thus, each invocation of "go get" yields a self-contained directory which can be used to build and develop the go-gotten package.
Downsides:

"vendor" doesn't currently work without $GOPATH (#14566); arguably this is just a bug
This would leave you with an unclean working copy, or alternately, "go get" could exclude the vendor directory it creates, but this gets confusing if the repo already contains some checked-in vendored packages.

Motivation:

Most users who "go get" do not care about seeing or modifying the dependencies; they just want to build or edit the package they directly reference.
This more closely matches the behavior of ~other languages' dependency tools, such as easy_install, cpan, gem, etc.

Once you get disciplined about Go workspaces, it turns out that it becomes very predictable where  you need to stop to detect the GOPATH - pretty much similar to the algorithm to detect the vendor directory.
I have been using this flawlessly for sometime:
$ which gopathme
gopathme: aliased to origDir="$PWD";lastDir=""; while [ "$lastDir" != "$PWD" ]; do if [ -d src ]; then export GOPATH="$PWD"; export PATH="$GOPATH/bin:$PATH"; echo $PWD; break; fi; lastDir="$PWD"; cd ../; done; cd $origDir

I have wrapped go with an bash script that actually tests for GOPATH before forwarding the shell call, and it works just as fine.

Coming from #14566, the smallest set of things I want when I have a vendor directory outside the GOPATH is:

have my vendor directory is managed like $GOPATH/src;
be able to specify the package name of my current directory.
This way, I can have my CI do reproductible builds using, for instance:

go build --local-package example.com/my-tools -o dist/my-command  ./cmd/my-command

Optionally, if go get can also pull to my vendor directory when outside of my GOPATH, that would be awesome.

I have an alternative, which is also compatible with the "src" detection above.
We currently have a mechanism for enforcing package import paths (import path checking).
It indicates the import path of a particular package. We can use this to synthesize a GOPATH, and to import subdirectories or nearby directories without relative imports.
Consider
directory $HOME/foo/bar
    package bar // import "github.com/broady/bar"
    import "github.com/broady/bar/baz"

We expect "baz" to be a subdirectory of $HOME/foo/bar We can contract github.com/broady/bar to . and treat it like import "./baz".
I'm working on a prototype and will write up a proposal in more detail. Evidently it has similar drawbacks to relative imports (nowhere to put object files), but has the advantage of retaining explicitness and not conflicting with how go get works.
(and while I was writing this, @MikaelCluseau replied. This proposal addresses his second point)

On 07/14/2016 10:13 AM, Chris Broadfoot wrote:

I'm working on a prototype and will write up a proposal in more
detail. Evidently it has similar drawbacks to relative imports
(nowhere to put object files), but has the advantage of retaining
explicitness and not conflicting with how |go get| works.

git is using a .git folder; I wouldn't find it awful if go did the
same. It could be $PWD/.go or $PWD/vendor/.go or even
$PWD/vendor/.pkg.
--
There are only two hard problems in distributed systems:
2. Exactly-once delivery

Guaranteed order of messages
Exactly-once delivery

I'm in favor of the original walk up until you find src proposal or walk up to the highest level `src dir.
As someone who works with a unique GOPATH per project with each project vendoring its dependancies -- I really like the gb model of auto detection of the GOPATH based on which project path you are in. Its just like git and it best matches the workflow I see developers use day to day which is switching between git repos that are all fully self contained gopaths in essence (or a project in gb terms).
I commonly see people work around existing gopaths by including build.shscripts that set the gopath to avoid the developer being required to set their environment when moving between git repos. In this development model it is expected that if you want to develop the project, you clone the repo with git. If you are consuming the project you are importing it with a vendor tool to an existing repo. Without repo including the build script then every time I move between git repos I would have to change my GOPATH env again.
With this proposal someone who normally uses something like git clone goes from doing:
git clone https://github.com/coreos/mantle
cd mantle
(now one can call ./build or other bash scripts to work on the repo and create a gopath)
To doing:
git clone https://github.com/coreos/mantle mantle/src/github.com/coreos/mantle
cd mantle/src
And now I am in the gopath and can execute any go commands requiring the path to be setup correctly. In the first example things like go list still don't work out of the box whereas with the proposal you have a properly setup go path and can make better use of go tooling.
Basically, for this work style, this proposal would eliminate a lot of bash glue in the example repo above as long as the new git command make sense to developers. Also, its not like this proposal stops people from using the old clone style and bash scripts.
I understand there are different working styles to consider here, I just wanted to chime in that for the work style I commonly see I am in favor of the original proposal.

On 07/14/2016 11:14 AM, Patrick Baxter wrote:

I understand there are different working styles to consider here, I
just wanted to chime in that for the work style I commonly see I am in
favor of the original proposal.

I don't think we are incompatible: you are actually getting a GOPATH,
while I was discussing about being outside the GOPATH.
If we take the nice git approach, go should look for a .go directory
in the CWD or any parent in the same filesystem. This directory would
mark what is currently "$GOPATH/src", while $GOPATH/pkg would be
.go/pkg. To support CI builds, we only need either a command line
argument, or a marker to (optionnaly) set package name of the CWD. This
marker could be in the .go directory.
--
There are only two hard problems in distributed systems:
2. Exactly-once delivery

Guaranteed order of messages
Exactly-once delivery

If the original proposal gets adopted it might also make sense to make a vendor auto set as the gopath rather then continueing to walk up the file tree to a src. That way you could cd into the vendor directory and have the normal go tools work on just the vendored code but also allow go get to work as vendoring tool.
The vendoring stuff would need to be figured out more before the go get stuff would be useful inside the vendor dir. However, making the auto-detect work in the meantime for vendor as well might still be desirable. It might even affect plans around standardizing the location of the manifest file and how many vendor dirs can exist per project and where they should be.

I am in the favor of the original proposal. Walking up to the src seems to be a great strategy unless it doesn't break packages with import paths with src inside. Do you have any input what's going to be the expected behavior if go is run inside a directory such as:
$GOPATH/src/github.com/someone/proj/src/cmd/cli

@rakyll I think almost every proposal will break something one way or another but walk up to source/walk up to .dotfile seems intuitive enough

Having all Github code in BigQuery will help identify potential problems like the one with src in import paths. Obviously Github != all Go code, but it's a solid start.

 It would create a new project and could serve as a introduction to new users. On first run it may look like:
~ $ go new
Enter a project name. This typically looks like: github.com/user/project
> user/entered/name
You do not seem to have a $GOPATH set. This is required for go to manage dependencies.
$GOPATH location [/home/username/go]:
>

The tool would then create the $GOPATH structure, and add it to wherever you add $GOPATH on your os. It might also copy the default go playground example, or similar, to the new project directory and cd there. It could also, optionally, add $GOPATH/bin to your $PATH, or at least give guidance on how go install works.
I think this would help new users understand the gopath structure hands-on, without having to change other tools.

@Abextm this is an interesting idea, but would you mind filing a separate issue for it? I don't want to distract from the central discussion here.

Thinking more about it, I'm confused about what problem this proposal is trying to solve.
I do have a workspace-centered workflow, which is very much like what this proposal would encourage. I do not set a default value for GOPATH. When I start working on a new project I create a directory for it and set GOPATH to that directory. Something akin to this:
$ export GOPATH=$PWD/project-foo
$ PATH=$GOPATH/bin:$PATH
$ cd $GOPATH
$ mkdir -p src/project-foo
$ vim src/project-foo/main.go
$ go install project-foo
$ project-foo

The point being, everything here works, from compilation to running. Notice that I have to do two things: set GOPATH and set PATH. Setting PATH is arguably pure comfort and not required, but as far as I understand this proposal, it's trying to address newcomers to Go and people who are not used to working with Unix-like operating systems. The second point that might generate disagreement is the usage of go install vs go build. If we are talking about newcomers, go build might be enough, and the above can be changed to this:
$ export GOPATH=$PWD/project-foo
$ cd $GOPATH
$ mkdir -p src/project-foo
$ vim src/project-foo/main.go
$ go build project-foo
$ ./project-foo

Now we are one step away from this proposal:
$ mkdir -p project-foo/src/project-foo
$ cd project-foo
$ vim src/project-foo/main.go
$ go build project-foo
$ ./project-foo

We have traded not having to tell newcomers about an environment variable for telling them to prefer go build over go install. Granted we would have gained the ability for doing this:
$ mkdir -p project-foo/src/project-foo
$ cd project-foo/src/project-foo
$ vim main.go
$ go build
$ ./project-foo

but note that for this particular case we do not need GOPATH. We need GOPATH only if we introduce packages:
$ mkdir -p project-foo/src/project-foo
$ cd project-foo/src/project-foo
$ mkdir pkg
$ vim pkg/pkg.go
# ...
$ vim main.go
# add something that requires import "project-foo/pkg"
$ go build
$ ./project-foo

This fails with the current state and would work with this proposal.
The downside I'm seeing is that since this proposal encourages using go build over go install, that also means that it encourages not having a pkg directory with a cache of all the packages (directly or indirectly) imported by project-foo, meaning slower build times.
Also note in that last example PWD is .../project-foo/src/project-foo, meaning that an user cd'ing around (in my experience, this is typical of people who do not feel comfortable with the command line, which might or might not equate the newcomers we are talking about here), will always be able to run go build project-foo and will end up with project-foo binaries all over the place. go install doesn't do that, which is another reason to recommend it over go build. But that means going back to the PATH problem.
Is there an additional required modification? Something like go install -run ..., meaning that it does what go install ... does, and it also runs the program. I don't really like it, but if the issue is environment variables, that's one way to solve it. Obviously another way is to extend go run to accept packages... :-P

I'm a very new user of Go, so I basically just fall into the camp of wanting to test out helloworld.go, it feels rather like 199x if I have to set an environment variable from my shell just to run my compiler or install a package. I get packages, I like them, but I also happen to like having reasonable defaults for tools and having those things in places like /etc/profile.d/ which a lot of Linux distributions use to setup the system wide default environment for a user. Why doesn't Go just use /etc/profile.d/ and set stuff there?  More advanced users can always override those values for whatever they want to do. I'm not sure remaking the wheel, in this situation, is entirely necessary.

I think the easiest way to help newcomers and don't break the existing way is the following:
Change go get in a way, that if GOPATH is not set, it will save the dependencies into a subfolder of the current folder named vendor (if this folder is not there: create it).
This way it is very easy: You can just build your package in the current folder and it will just work.
(A second step could be to advocate to create subpackages inside vendor/sub or vendor/lib and have the vendor folder added to the repo. Although you might argue that this would confuse the terminology and purpose of the vendor folder.)

Why doesn't Go just use /etc/profile.d/ and set stuff there?

We don't need to set the env variable and mess with the environment. All we have to ensure the entire tooling has a sane default if nothing is set. Free, dependency-free, cross-platform solution if the goal is to make GOPATH optional.

FWIW a (arguably pretty naive)
curl https://api.godoc.org/packages | jq '.results[].path' | grep '/src/' | wc -l

turns up 4184 import paths currently on godoc.org that would not work with this proposal and might lead to surprising results if GOPATH ever is accidentally not set (whereas now, if it is not set, there will just be a safe error). They include a lot of vendored stuff and projects that use a custom GOPATH (and might thus even, individually, benefit from this) but I'd still find it surprising if a go get suddenly deposits stuff deeply below my $GOPATH (just because I happened to accidentally run a shell without GOPATH set explicitly).
Just as a different variant: There are system-specific environment variables that tell you where to put data or configs and the most correct solution under a modern linux might be to use something like $XDG_DATA_DIR/go. Not that I'm claiming that this is a good idea.
Personally, I think all of the things proposed here can lead to unwanted side-effects, if $GOPATH is not set, be that because it wasn't set yet, or because of an accidental non-login-shell or something at some point in time. Thus I'm in favor of either not changing the current behavior or to default to a predictable directory (and of those I'd use $HOME, but I'm openly biased as that's my current setup).
Also, in response to people suggesting using a subdirectory of $GOROOT, or (like python) prefix/whatever: This will disallow using a distribution-provided go installation with go get, as $GOROOT there is most often not user-writable.

@Merovius I get your point, but doing a random sampling of the packages considered in that count, after looking at 5 of them, none of them are go-get'able, and in the cases that I looked at, the src directory is there because that's where their "workspace" starts. Look at the import statements in the packages: instead of e.g. import "github.com/kpumuk/metricsd/src/metricsd/config" it says import config.

@Merovius I get your point, but doing a random sampling of the packages considered in that count, after looking at 5 of them, none of them are go-get'able, and in the cases that I looked at, the src directory is there because that's where their "workspace" starts. Look at the import statements in the packages: instead of e.g. import "github.com/kpumuk/metricsd/src/metricsd/config" it says import config.

@mem fair enough (I don't think that matters particularly, but who am I to argue): Searching for /src/ on the HTML index (which only includes go-get'able packages) gives 963 hits.
But really, go-get'able or not is besides the point, in my opinion. They are buildable. And the negative side-effects are mostly independent of whether or not they intend you to set GOPATH to a subdir of the repo.
Anyway. I just wanted to provide some actual quantitative perspective on this. And state my technical objections to this proposal (namely that it makes it somewhat unpredictable what'll happen if GOPATH in some session isn't set, accidentally). I just don't think this heuristic is very good, is all.

@Merovius my proposal actually takes care of this, because it never automatically sets, instead it asks for the first time and saves for later. Roll back to my proposal to see how that works.
Here again straight from my memory:

have a tool that looks if either $GOPATH is set or a .gopath hidden file indicates the $GOPATH
if only .gopath is found, set $GOPATH globally to that
if not, ask where to put it with a sensible default
if an answer is given, put .gopath there so it will automatically work the next time, and set $GOPATH
this tool should be run by go get etc if no gopath is set, just a simple invocation to check

Hello,
What is the status of this proposal?
If it's stalled, I'd like to make my own, simpler, proposal along the lines of  https://github.com/golang/go/issues/12488#issuecomment-137596005.

@davecheney I'm happy for you to make a counterproposal here, unless it is not about automatically detecting GOPATHs at all.

TL;DR - I want to propose that GOPATH defaults to $HOME.
On Mon, Sep 26, 2016 at 9:35 AM, Andrew Gerrand<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney I'm happy for you to make a
counterproposal here, unless it is not about automatically detecting
GOPATHs at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/12488#issuecomment-249453949, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-3HUF6GkN3RRthEjd9jelKKlCcqks5qtwU-gaJpZM4F3oTt
.

@davecheney, not until we nuke the "pkg" directory. I'd like to add proper caching to cmd/go early in the Go 1.9 cycle, and then we could probably ditch pkg.

@branfitz is that because I suggested GOPATH=$HOME, if I suggested an
alternative location like GOPATH=$HOME/gocode would that unblock this
proposal so we don't have to wait til /pkg is removed ?
On Mon, Sep 26, 2016 at 9:53 AM, Brad Fitzpatrick<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney, not until we nuke the "pkg"
directory. I'd like to add proper caching to cmd/go early in the Go 1.9
cycle, and then we could probably ditch pkg.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/12488#issuecomment-249454812, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA7gJLMgZcip7HinQlVCSho31u-Qyks5qtwljgaJpZM4F3oTt
.

@davecheney GOPATH defaulting to home won't fix the "complex CI build" issue, but is nice. If pkg is removed at some point, all we'll need will be to have a flag to specify the position of the CWD in the go import tree.

If you don't want GOPATH=$HOME then all you have to do is set $GOPATH
manually. For 100% of Go users today, nothing has changed.
On Mon, Sep 26, 2016 at 10:00 AM, Mikaël Cluseau<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney GOPATH defaulting to home
won't fix the "complex CI build" issue, but is nice. If pkg is removed at
some point, all we'll need will be to have a flag to specify the position
of the CWD in the go import tree.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/12488#issuecomment-249455191, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA2AZGcpxM-trMf7TCv_ghstjS6lFks5qtwsvgaJpZM4F3oTt
.

@branfitz is that because I suggested GOPATH=$HOME, if I suggested an
alternative location like GOPATH=$HOME/gocode would that unblock this
proposal so we don't have to wait til /pkg is removed ?

I wouldn't object, at least. But I (and I think others) would object to Go automatically creating a $HOME/pkg dumping ground, surprising users.

@bradfitz is there a plan to do away with pkg? It does not seem easy to me, it is an important performance optimization, especially if you are importing cgo packages.
What if an unset GOPATH implied pkg being somewhere off in a temp file system?

On Mon, Sep 26, 2016 at 10:04 AM, Brad Fitzpatrick<EMAIL_ADDRESS>
wrote:

@branfitz is that because I suggested GOPATH=$HOME, if I suggested an
alternative location like GOPATH=$HOME/gocode would that unblock this
proposal so we don't have to wait til /pkg is removed ?
I wouldn't object, at least. But I (and I think others) would object to Go
automatically creating a $HOME/pkg dumping ground, surprising users.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/12488#issuecomment-249455370, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA69DmumnKzwQvmL8_4Yhlb6zOevyks5qtwvxgaJpZM4F3oTt
.

On 09/26/2016 11:03 AM, Dave Cheney wrote:

If you don't want GOPATH=$HOME then all you have to do is set $GOPATH
manually. For 100% of Go users today, nothing has changed.

I agree, I just want to underline the path that put me in this thread,
which is "how to build easily in gitlab-ci", where your git repo is in
$HOME/build/some-variable-part/repo-name. We need to be able to say "hey
go, this folder where you are is the import path for mycomp.com/my-project".

The former. The latter may have to set an GOPATH environment variable, this
is no different to what they have done for Go 1.1 to Go 1.7.
On Fri, Dec 11, 2015 at 10:30 AM, Dmitri Shuralyov<EMAIL_ADDRESS>
wrote:

Is this proposal about helping people who don't know/understand GOPATH
workspaces be able to use Go? Or is it about making it more convenient for
people who know it but deal with many systems, CI, etc.?
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/12488#issuecomment-163785836.

@MikaelCluseau in that case nothing changes, the CI user will have to set GOPATH, just as they do today.

$HOME/build/some-variable-part/repo-name. We need to be able to say "hey
go, this folder where you are is the import path for mycomp.com/my-project".

I'd say this is out of scope. Various CI tools like travis have worked around the fact that the checkout of the go project is not the root of the workspace. My proposal to set a default GOPATH does not change this.

On 09/26/2016 11:10 AM, Dave Cheney wrote:

@MikaelCluseau https://github.com/MikaelCluseau in that case nothing
changes, the CI user will have to set GOPATH, just as they do today.

yes, that's why I said it doesn't solve the problem. But I understand it
can be seen as a different issue.

@bradfitz is there a plan to do away with pkg? It does not seem easy to me, it is an important performance optimization, especially if you are importing cgo packages.

Yes. That is #4719. It will still exist, but instead of being at $GOPATH/pkg, it'll be at a OS- and user-specific cache directory, and it'll be a cache of outputs from actions of content-addressable inputs. Which means go test -i as a necessary practice goes away, etc.

The related issue of pkg as a dumping ground is https://github.com/golang/go/issues/4719 "cmd/go: think about whether "pkg" needs to exist under $GOPATH".
I like GOPATH=$HOME as a default if not set.

This proposal only changes the experience for newcomers who have not chosen to set a GOPATH variable.
At the moment all the documentation says "you have to set a GOPATH", then people get distracted and upset because they don't understand why they have to do this.
By choosing a default GOPATH, we can make our documentatation easier because we can say things like
go get github.com/foo/bar

will check out the github.com/foo/bar repo into $HOME/gocode/src/github.com/foo/bar.
We don't need to distract newcomers with having to set an env var, all we need to do is put a little parenthetical note at the bottom of the page
$HOME/gocode is the default path to your go workspace. If you want to change this path, set the GOPATH variable to something of your choosing.

I foresee problems here though when you e.g. start using a new shell and in the old situation the error message would inform you that it's not set up correctly yet. With your proposal you would silently get the code checked out and duplicated, and you end up with a mess, if you don't use the same GOPATH. in my proposal that doesn't happen, because any new shell will automatically pick up the same old directory, it works when you migrate to a new system and will gently put the new users through it.

Also, if you add this stuff to an independent tool, you can backport it to old versions where necessary.

@rsc as the proposal arbitrator would you welcome a proposal to provide a default GOPATH if one is not explicitly set in the environment?

I think we're going with #17262.


Props (e.g., in T::Struct) don't declare their corresponding instance variables

Input
→ View on sorbet.run
# typed: strict
class A < T::Struct
  extend T::Sig

  prop :foo, String

  sig {returns(String)}
  def bar
    @foo
  end
end

Observed output
editor.rb:9: Use of undeclared variable @foo https://srb.help/6002
     9 |    @foo
            ^^^^
Errors: 1

Expected behavior
I expect this instance variable to already be declared and already have type String

I'm not sure if we want to let users depend on the fact that props on a T::Struct are backed by instance variables of the same name. This is currently true but we may want to treat it as merely an implementation detail that may change at any time.
Is there a situation where using the getter/setter methods for the struct class doesn't work? As far as I can tell, every time you would want use an ivar generated by a prop, you could just use the getter/setter methods generated by that prop.

https://sorbet.run/#%23 typed%3A strict
class A < T%3A%3AStruct
  extend T%3A%3ASig

  prop %3Afoo%2C String

  sig {void}
  def flip!
    foo %3D foo.reverse
  end
end
# typed: strict
class A < T::Struct
  extend T::Sig

  prop :foo, String

  sig {void}
  def flip!
    foo = foo.reverse
  end
end

editor.rb:9: Method reverse does not exist on NilClass https://srb.help/7003
     9 |    foo = foo.reverse
                  ^^^^^^^^^^^
Errors: 1

Although I suppose I can work around this by using self.foo = foo.reverse

In any event, we have a ton of legacy code that relies on this behavior that someone is going to have to fix at some point

This works now for T::Struct.

Would it be possible to have this same behaviour expanded to T::InexactStruct?


How to run Plaid Link in custom .NET applications?

I need to authenticate users' accounts using plaid API in .NET web application. I was struggling to integrate this project in my .NET 4.7 web application but I could not do so. Then I just included the Plaid.Link project in my solution and ran in the new instance in visual studio, it ran in the browser and created a local link. i.e. _https://localhost:44359/_. I then used it's link in my project and hit that link to create a flow to generate access link eventually. The project stores access link and access link in plaid_access_token.tmp in temp folder step by step. I understand Access token can be used after the completion of the flow to call other API end points. below screenshots are attached for all the steps.
Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

Step 6:

I have 2 questions/ problems right now.
1- What I am doing is right or there is another better way of doings things? if yes, what steps should I follow.
2- When I run the project using above steps, it shows blue screens at the start and end of the flow. And in second step there is "Example uses Plaid to link your bank". How to avoid blue screen and change text at picture number two attached?

Yes, that's exactly what you should be doing. The access token at the end is what you need to provide to the other APIs.
So the blue screen and everything visible there are part of the html file produced by the Plaid.Test project. You have full control over those to change as you like. However, the screens where the Plaid dialog is open are subject to their control. You can review this documentation to see how to customize that screen, but the customization options are limited because Plaid controls those screen.

Hope this helps.

@viceroypenguin,
In point 2. you are saying blue screen is part of Plaid.Test. But that project is not included in my development solution. I have only imported Plaid.Link. where that blue screen is popping up from in Plain.Link project. how to go bank in my own project after creating access token. Kindly advice. Thank you.

I am saying that the blue screen is part of the running project. Look at the default page for your application (index.html, Index.cshtml, etc.). The text box for the plaid access token and the blue screen are on the same page, whether in the html or in the attached css. It is not part of Plaid directly, it is part of your code, so you have the ability to change it.

Got it. But it's not in index.cshtml.
Can you help me find that from where that blue screen is popping up in Plain.Link project?

The blue itself is probably coming from wwwroot/stylesheets/app.scss, given that it's part of the background.

I need to authenticate users' accounts using plaid API in .NET web application. I was struggling to integrate this project in my .NET 4.7 web application but I could not do so. Then I just included the Plaid.Link project in my solution and ran in the new instance in visual studio, it ran in the browser and created a local link. i.e. _https://localhost:44359/_. I then used it's link in my project and hit that link to create a flow to generate access link eventually. The project stores access link and access link in plaid_access_token.tmp in temp folder step by step. I understand Access token can be used after the completion of the flow to call other API end points. below screenshots are attached for all the steps.
Step 1:
Step 2:
Step 3:
Step 4:
Step 5:
Step 6:
I have 2 questions/ problems right now. 1- What I am doing is right or there is another better way of doings things? if yes, what steps should I follow. 2- When I run the project using above steps, it shows blue screens at the start and end of the flow. And in second step there is "Example uses Plaid to link your bank". How to avoid blue screen and change text at picture number two attached?

hey, How you had done this? Please guide a lill bit.


Conflict when using together with Rest-Client library

I installed rest-client library using sparks command line. When i try to load the rest-client library in a Rest Controller, i have the following error
PHP Fatal error:  Cannot access protected property Example::$rest in /home/tran/public_html/peacemoon/system/core/Loader.php on line 1095

This is the code in my Rest Controller
public function test_get() {
	$this->load->spark('restclient/2.0.0');

	// Load the library
	$this->load->library('rest');

	$this->response('hello', 200);
}

I was able to make my code to run by change all the variables in REST_Controller.php from "protected" to "private"
private $rest_format = NULL; // Set this in a controller to use a default format
private $methods = array(); // contains a list of method properties such as limit, log and level
private $request = NULL; // Stores accept, language, body, headers, etc
private $response = NULL; // What is gonna happen in output?
private $rest = NULL; // Stores DB, keys, key level, etc
private $_get_args = array();
private $_post_args = array();
private $_put_args = array();
private $_delete_args = array();
private $_args = array();
private $_allow = TRUE;

// List all supported methods, the first will be the default format
private $_supported_formats = array(
	'xml' => 'application/xml',
	'rawxml' => 'application/xml',
	'json' => 'application/json',
	'jsonp' => 'application/javascript',
	'serialized' => 'application/vnd.php.serialized',
	'php' => 'text/plain',
	'html' => 'text/html',
	'csv' => 'application/csv'
);

This may be related to this bug report: https://github.com/philsturgeon/codeigniter-template/issues/22

hey, the final fixed is still not pulled to the latest Rest Server library ?

REST_Controller is to be extended, I prefer its properties to be protected, not private.

Agreed

then what should be the correct approach if we want to use the same class as a Rest server and Client together ?

That isn't maintained by us is it?

First thoughts:

The REST library to be "adopted" by this project. :-)
It to be renamed as Rest_client.
A test showing them working simultaneously to be prepared.

Meanwhile...
$this->load->library('rest', $config, 'rest_client');

I will confess I have never used Rest_client nor probably will I ever. But I am game if everyone else is =)

In my demo with the Rest Client library I did not extent the controller class from REST_Controller, but at least the following commit show how can the name conflict be resolved:
https://github.com/ivantcholakov/starter-public-edition-3/commit/0030a94d3c20e853c3baf823312eee9ae4db9389

Also, the REST client library should be renamed, because the configuration file is named as rest.php. This is a second name conflict.
With a renamed client library, if we want to define some configuration options, its configuration file will be named as rest_client.php.

@chriskacerguis
What do you think about putting the REST client library an the Curl library in this project? I can make the initial commits and put some tests. Then (@softwarespot) conversion to PHP 5.4 follows and some polishing.

If I have time =)

No problem, I can cover the whole thing.

http://forum.codeigniter.com/thread-62631-post-321417.html


Calculate Anything extension crashed [ULauncher]

Describe the bug
Calculate Anything extension crashed after I added it to ULauncher
To Reproduce
I just added the extension and that happened.
Logs
I couldn't find any logs at ~/.cache/com.github.tchar.calculate-anything/log.
Screenshots

Desktop

OS: Debian 12
Linux: Linux 6.1.0-22-amd64
Desktop: GNOME Wayland

Additional context
I am not a expert when it comes to installing python packages... especially on linux.
I don't know what is the best way to install pip packages as of PEP668.
I tried to install the dependencies (requests pint simpleeval parsedatetime) by creating a venv in /usr/local/venv.
If you have any better way of installing pip packages, feel free to tell me... Maybe the dependencies aren't recognised by the extension.

I am not sure if Ulauncher dev team has enabled a virtualenv per extension, but for now you should install the dependencies using python -m pip install/python3 -m pip install outside of virtual environments

In my case, this did the trick :
sudo apt install python3-pint python3-simpleeval python3-parsedatetime python3-tz

Updating these fixed it for me on Arch:
yay -Sy --needed python-pint  python-simpleeval python-parsedatetime python-pytz

This person solved it in their nix config, which I copied for mine :D https://github.com/b3nj5m1n/dotfiles/blob/ca39a62644bc97ec9e61dea3ad63cfdfb4aa6ef1/nix/modules/nixos/ulauncher.nix

Getting the same issue issue (I think?) under Bluefin (Silverblue / Universal Blue). I'm new to Linux desktops (well; that's not true, but I didn't run one in 15 years as my daily driver until today)...but I'm happy to help debug or whatnot!

@toriacx, Do any of the solutions above work for you?
Generally, the package issue is hard to fix. Normally, the extensions should run in their own virtual environment, and honestly, from the u-launcher perspective, it should not be that hard to implement.


[4.0] upgrade: fix epmd during upgrade

After the package upgrade for epmd it will only listen on
<IP_ADDRESS> which will prevent rabbitmq-server for working, as
it will try to obtain a port on all interfaces by asking epmd
on the appropiate interface but will fail to do so on any interface
other than <IP_ADDRESS>
With this we patch epmd to listen on all interfaces after the upgrade
so it will be ready for when rabbit comes up. The systemd override will
get afterwards be set to listen only in the proper interface as soon as
the crowbar cookbook is run on the admin node.
Note: This is only needed in 7 -> 8 upgrade, should not be needed in the future

currently testing it, seems to work as expected

Tested and works, ready for merge


[Bug report]plugin-docsearch: Using the vue theme page will cause the search plugin to render repeatedly

Bug report
I used the vuepress-docSearch plugin in my theme, but it seems to be rendered repeatedly as shown in the figure below. I am very surprised that such a thing will happen. If the page is rendered with markdown page, it will not happen, but if it is used with vue page, it will happen. .
Description

The plugin-docsearch plugin repeated rendering on my vue theme page.
Steps to reproduce

Use Search "Mac" on my homepage,
After the jump Search ”vscode"
After the jump Search ”Mac"

Reproduction link / repo:
https://www.qbenben.com/

Expected behavior
The plugin-docsearch plugin only render once

Screenshots

render 4 time
But it is normal to search only after refreshing the md page

Environment info

Browser:

  System:
    OS: macOS 12.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 30.88 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 12.22.0 - /var/folders/p3/55bvbjg57lzb1d2b_mwbzykw0000gn/T/yarn--1641138157713-0.534447467104483/node
    Yarn: 1.22.4 - /var/folders/p3/55bvbjg57lzb1d2b_mwbzykw0000gn/T/yarn--1641138157713-0.534447467104483/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v12.22.0/bin/npm
  Utilities:
    Git: 2.30.1 - /usr/bin/git
  Browsers:
    Chrome: 96.0.4664.110
    Edge: Not Found
    Firefox: Not Found
    Safari: 15.1
  npmPackages:
    @vuepress/bundler-vite:  2.0.0-beta.31 (2.0.0-beta.32)
    @vuepress/bundler-webpack:  2.0.0-beta.30
    @vuepress/cli:  2.0.0-beta.31 (2.0.0-beta.32)
    @vuepress/client:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/core:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/markdown:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-active-header-links:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-back-to-top:  2.0.0-beta.30 (2.0.0-beta.32)
    @vuepress/plugin-container:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-debug: Not Found
    @vuepress/plugin-docsearch: 2.0.0-beta.29 => 2.0.0-beta.29
    @vuepress/plugin-external-link-icon:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-git:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-google-analytics:  2.0.0-beta.29
    @vuepress/plugin-medium-zoom:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-nprogress:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-palette:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-prismjs:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-pwa: Not Found
    @vuepress/plugin-pwa-popup: Not Found
    @vuepress/plugin-register-components: Not Found
    @vuepress/plugin-search: Not Found
    @vuepress/plugin-shiki: Not Found
    @vuepress/plugin-theme-data:  2.0.0-beta.29 (2.0.0-beta.32)
    @vuepress/plugin-toc: Not Found
    @vuepress/shared:  2.0.0-beta.28 (2.0.0-beta.32)
    @vuepress/theme-default:  2.0.0-beta.31 (2.0.0-beta.32)
    @vuepress/utils:  2.0.0-beta.28 (2.0.0-beta.32)
    vue:  3.2.26
    vue-loader:  16.8.3
    vue-router:  4.0.12
    vuepress: ^2.0.0-beta.31 => 2.0.0-beta.32
    vuepress-vite: 2.0.0-beta.31 => 2.0.0-beta.31 (2.0.0-beta.32)
    vuepress-webpack: 2.0.0-beta.31 => 2.0.0-beta.31

unmark

After my testing, using the keyboard(like cmd+k) causes the search box to be rendered repeatedly,
but using the mouse works fine!!!

reproduce
Adding Extra Pages making a RouterLink jump on other page will cause the search component to be destroyed and re-rendered, but the keyboard event bound to docSearch is not successfully destroyed, resulting in multiple search boxes being generated after the keyboard event is triggered.

Of course, I also tried to handle the cancellation event in onBeforeUnmount. But the removeEventListener cannot be executed because the listener cannot be obtained.

What makes me wonder is why the extra page created with vue is different from the page generated with markdown: it doesn't seem to feel like a single page application.

Try providing a minimal reproduction with @vuepress/theme-default, I will have a look later. @Zhengqbbb

I still can not reproduce it. The listener is added by docsearch, and I am not sure if there is a way to notice them to destory. You may give a little help here.
Also, if the extra pages are using the default layout, they won't have any problems, but if they are using a different layout, then that's expected.

Track https://github.com/algolia/docsearch/issues/1363

Hi Mr.Hope, sorry for the delay in minimizing the example. ❤
github: https://github.com/Zhengqbbb/vuepress-test
page: https://test.qbenben.com/
reproduce

In the following example, after I searched twice on

the home page, the box did not disappear. Can view video

Use shortcut keys. Command + k => Search Text : “doc”
Then, command + k => Search Text : “test”

https://user-images.githubusercontent.com/40693636/163668387-1797a20e-0c17-4431-89ad-68c3f78b1fc2.mp4

Sorry for forgetting noticeing you I made a repro on my site, I already open an issue to docsearch repo, and you can track that issue to see how we can solve it.


Validate channel inputs - [merged]

In GitLab by @dstansby1 on Oct 6, 2020, 13:03
Merges channel-validation -> master
Fixes https://gitlab.com/LMSAL_HUB/aia_hub/aiapy/-/issues/57
I successfully made a decorator! I think this is the right approach. If it is, then I can look at rolling it out to the rest of the codebase.

In GitLab by @dstansby1 on Oct 7, 2020, 02:03
added 1 commit
62b2a35c - Validate channel inputs
Compare with previous version

In GitLab by @wtbarnes on Oct 6, 2020, 15:01
This is great! I think this could be applied a few other places other than channel as well. Just one question...where is the decorator? :sweat_smile:

In GitLab by @dstansby1 on Oct 7, 2020, 05:44
I think I found everything that takes a channel as input. I originally wrote the decorator to allow an arbitrary argument name, and specification of a custom channel list, but I think everywhere uses 'channel' as an argument name and allows any of the valid channels, so I could get rid of these generalisations?

In GitLab by @wtbarnes on Oct 7, 2020, 07:17
Commented on aiapy/psf/psf.py line 156
@validate_channel('channel', valid_channels=[94, 131, 171, 193, 211, 304, 335]*u.angstrom)

I think this is the only case where not all channels are valid.

In GitLab by @dstansby1 on Oct 7, 2020, 02:03
:rolling_on_the_floor_laughing: should be there now

In GitLab by @codecov on Oct 7, 2020, 02:10
Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7602268). Click here to learn what that means.
The diff coverage is 95.23%.

@@            Coverage Diff            @@
##             master      #88   +/-   ##
=========================================
  Coverage          ?   97.11%
=========================================
  Files             ?       15
  Lines             ?      451
  Branches          ?        0
=========================================
  Hits              ?      438
  Misses            ?       13
  Partials          ?        0

Impacted Files
Coverage Δ

aiapy/util/decorators.py
94.73% <94.73%> (ø)

aiapy/response/channel.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7602268...96ec257. Read the comment docs.

In GitLab by @dstansby1 on Oct 7, 2020, 05:43
added 1 commit
96ec2575 - Add decorator to more functions
Compare with previous version

In GitLab by @dstansby1 on Oct 7, 2020, 08:48
Commented on aiapy/psf/psf.py line 156
changed this line in version 4 of the diff

In GitLab by @dstansby1 on Oct 7, 2020, 08:48
added 1 commit
740932d5 - Apply 1 suggestion(s) to 1 file(s)
Compare with previous version

In GitLab by @wtbarnes on Oct 7, 2020, 07:17
Commented on aiapy/calibrate/util.py line 107
This check is now redundant and can be removed. The associate test for this is also what is causing the CI to fail. It can be removed as well.

In GitLab by @wtbarnes on Oct 7, 2020, 07:21
I think keeping it general is good. The custom channel list is actually applicable in the aiapy.psf.psf function since there is no PSF for the UV and visible channels. I also prefer having to explicitly state what argument is being validated.

In GitLab by @dstansby1 on Oct 7, 2020, 08:53
resolved all threads

In GitLab by @wtbarnes on Oct 7, 2020, 10:25
approved this merge request

In GitLab by @wtbarnes on Oct 7, 2020, 10:25
unapproved this merge request

In GitLab by @dstansby1 on Oct 7, 2020, 08:52
added 1 commit
4dfe654c - Fix test
Compare with previous version

In GitLab by @dstansby1 on Oct 7, 2020, 08:52
Commented on aiapy/calibrate/util.py line 107
changed this line in version 5 of the diff

In GitLab by @wtbarnes on Oct 7, 2020, 10:26
approved this merge request

In GitLab by @wtbarnes on Oct 7, 2020, 10:26
mentioned in commit a0ae95d8ca17a3ae5c893b9f6366e5746664ac6e


Automated testing with Jest

Had a hell of a time trying to figure this one out. Thought I would share the solution I found here to help anyone else trying to set up automated Jest tests with ReactChessboard.
Solution for writing automated tests with Jest

npx create-react-app react-chessboard-jest-testing, cd react-chessboard-jest-testing
npm i react-chessboard
npm i --save-dev react-dnd-test-utils react-dnd-test-backend

Getting Jest to play nicely with ESM modules

package.json

{
  ...
  "jest": {
    "transformIgnorePatterns": [
      "/node_modules/(?!(@?react-dnd[^/]*|dnd-core)/)"
    ]
  }
}

Writing the test

src/App.test.js

import React from 'react';
import { act } from 'react-dom/test-utils';
import { cleanup, render } from '@testing-library/react';
import { fireDragDrop, tick } from 'react-dnd-test-utils';
import { Chessboard as ReactChessboard } from 'react-chessboard';

/* act and await tick to ensure setup animation completes
 * (and sets waitingForAnimation to false) before running assertions
 */
beforeEach(async () => {
  await act(async () => {
    const props = {
      position: "rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1", // starting position
      onPieceDrop: () => true,
      animationDuration: 0, // **important** to not slow down your tests
    }
    render (<ReactChessboard {...props} />);
    await tick();
  })
})

afterEach(() => {
  cleanup()
})

test('e2 to e4', async () => {
  let e2pawn = document.querySelector('[data-square=e2] [draggable]');
  let e4square = document.querySelector('[data-square=e4]')

  expect(e2pawn).toBeInTheDocument();
  expect(e4square.querySelector('[draggable]')).not.toBeInTheDocument();
  await fireDragDrop(e2pawn, e4square);
  expect(e2pawn).not.toBeInTheDocument();
  expect(e4square.querySelector('[draggable]')).toBeInTheDocument();
})

Tested on:

create-react-app v5.0.1
node v16.14.0
Ubuntu 20.04.4 LTS Focal x86_64
npm list:
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
Brainstorming possible improvements
Using querySelector is not necessarily a best practice. By adding aria roles and labels, those calls could be replaced with the more standard testing-library queries.
test('can find white pawn', () => {
  render(
    <>

    </>
  )

  let e2pawn = screen.getByRole('widget', { name: /white e2 pawn/i });
  expect(e2pawn).toBeInTheDocument();
})

I'm by no means an expert on accessibility. I went to both chess.com and lichess.org to see how they approach this, and it seems that they don't yet have any support for screen readers. Would be nice to get input from someone more knowledgeable about accessibility before making these changes and to think more broadly about the experience for visually impaired players.

This is incredible, I've only had a brief read through as I'm very busy lately but when I get time I will try to turn this into some documentation that everyone can reference if they need to test, and I'll try to have a think about how testing could be improved/made easier as you suggested
Thank you so much for documenting this

Hello, I am Rahul a blind person. I am regular screen reader user. As mentioned here I also notice that the library does not work well with the screen readers. . This can have huge impact. any website wich uses this library, will be completely  in accessible for blind people like me. If allowed ,I would like to work and help in fixing this.


pip always make vs2015 unresponsive

When I use pip to install modules ,vs2015 will be always unresponsive.
Thers is another problem. Using pip I can't install some modules.
For example,
----- Installing 'Scrapy' -----
Collecting Scrapy
Could not fetch URL https://pypi.python.org/simple/scrapy/: There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) - skipping
Could not find a version that satisfies the requirement Scrapy (from versions: )
No matching distribution found for Scrapy
----- Failed to install 'Scrapy' -----

Thanks for the example.
Firstly, are you using pip from the Python Environments window?  They should do the same thing, but as it is affecting the UI, it will matter to us which way you are doing it.
For the SSL issue, this probably means that you need to upgrade Python - which version are you currently using? Alternatively, you may have a special "openssl" or "cryptography" package installed that is out of date. Can you try opening a command prompt for your environment and running pip install scrapy directly to see if the error is the same?

Yes, when install VS2015, I check install PTVS .
I run pip install scrapy in command, the Error is same.

What do you see if you run python -V?


Cannot useRef with functional components

First, thanks for the library.  One of the examples shows a useRef to get a handle to a layer.  However, when I tried that with DynamicLayer so that I could trigger an Identify task later, React of course complained that I could not use refs with such a component.
Am I missing something?  Thanks for any help.  If this is the wrong venue for such a question, please direct to the right spot.  Thank you.

Wow I guess I never tested the refs before.  You're right, this is a problem.  I need to wrap the underlying EsriLeafletLayer in a forwardRef call to get this working, or make it a class component.  I'll try to fix this as soon as I can.  Currently, a crappy workaround is to do this:
import { EsriLeafletLayer } from "react-esri-leaflet";

const Map = () => {
  var dynamicMapLayerRef = React.useRef();

  return (
    <MapContainer ... >=
      <EsriLeafletLayer
        layerType="dynamicMapLayer"
        ref={dynamicMapLayerRef}
        url="your_layer_url"
      />
    </MapContainer>
  );
};

Here's a working example of that.  Right this moment it seems that dynamic map layer url is not working on the arcgis side, but the ref to the layer is still working.
I'll get working on fixing this for real hopefully within the next few days.

This is fixed now. Upgrade to 1.3.0 and you should be able to use refs normally as described in the docs.  The examples also now have working examples of using refs (check out the <FeatureLayer /> component in either example folder). Let me know if you have any more issues with this.

Just wanted to thank you very much for the fix!   You saved our project.


feat: add arm64 support

CONTEXT
BS from last version is not available on mac arm.
CHANGE SCOPE
I added arm64 support in cpp file.
RESULT
Tests pass correctly. Crate form dir is correctly works on mac.
ADDITIONAL
I added gitignore because terget is in main dir generated in build process 🗑

Looks good, thanks for contributing!

Do you need help with GitHub Actions to automate your deployments to crates.io?

I was actually just looking at this the other day. I just set up build and test with github actions, are you familiar with getting cargo publish set up as well?  I'm not sure how the credentials work in that case.

I am familiar with GHA, so it's not a problem to configure it. I am big enthusiasts of automation of packages :)

So if you are interested in help in that area let me know. You can create issue and assign me. I am on vacation but in the next week I can help you with :)

Great, I created an issue, I believe if you leave a comment on it I can assign you to it.


Deploy Multicall3 to DFK Chain

Hello,
Here are the info about the chain :
ChainID: 53935
Network Name: DFK Chain
RPC URL:  https://subnets.avax.network/defi-kingdoms/dfk-chain/rpc
Currency Symbol: JEWEL
Block Explorer URL: https://subnets.avax.network/defi-kingdoms
I've sent few JEWEL to the deployer account to cover the deploy.

I'm getting the following RPC error:
{
  "code": -32000,
  "message": "tx.origin 0x05f32B3cC3888453ff71B01135B34FF8e41263F2 is not authorized to deploy a contract"
}

Seems like we need to get that deployer address authorized to deploy a contract? I'm not familiar with DFK Chain so not sure how this works

I’ve checked their discord and it seems they might open it up soon on next chain update.
I will check it once it’s done and come back here.
Thanks for your help and work

Going to close this for now since there's not currently anything actionable, feel free to reopen once it can be deployed


yarn format is not working?

This issue occurs on my local pc and gitpod both.
 web % yarn prettier:fix
yarn run v1.22.19
$ prettier --write
Usage: prettier [options] [file/dir/glob ...]

By default, output is written to stdout.
Stdin is read if it is piped to Prettier and no files are given.

Output options:

  -c, --check              Check if the given files are formatted, print a human-friendly summary
                           message and paths to unformatted files (see also --list-different).
  -l, --list-different     Print the names of files that are different from Prettier's formatting (see also --check).
  -w, --write              Edit files in-place. (Beware!)

Format options:

  --arrow-parens <always|avoid>
                           Include parentheses around a sole arrow function parameter.
                           Defaults to always.
  --no-bracket-spacing     Do not print spaces between brackets.
  --embedded-language-formatting <auto|off>
                           Control how Prettier formats quoted code embedded in the file.
                           Defaults to auto.
  --end-of-line <lf|crlf|cr|auto>
                           Which end of line characters to apply.
                           Defaults to lf.
  --html-whitespace-sensitivity <css|strict|ignore>
                           How to handle whitespaces in HTML.
                           Defaults to css.
  --jsx-bracket-same-line  Put > on the last line instead of at a new line.
                           Defaults to false.
  --jsx-single-quote       Use single quotes in JSX.
                           Defaults to false.
  --parser <flow|babel|babel-flow|babel-ts|typescript|espree|meriyah|css|less|scss|json|json5|json-stringify|graphql|markdown|mdx|vue|yaml|glimmer|html|angular|lwc>
                           Which parser to use.
  --print-width <int>      The line length where Prettier will try wrap.
                           Defaults to 80.
  --prose-wrap <always|never|preserve>
                           How to wrap prose.
                           Defaults to preserve.
  --quote-props <as-needed|consistent|preserve>
                           Change when properties in objects are quoted.
                           Defaults to as-needed.
  --no-semi                Do not print semicolons, except at the beginning of lines which may need them.
  --single-quote           Use single quotes instead of double quotes.
                           Defaults to false.
  --tab-width <int>        Number of spaces per indentation level.
                           Defaults to 2.
  --trailing-comma <es5|none|all>
                           Print trailing commas wherever possible when multi-line.
                           Defaults to es5.
  --use-tabs               Indent with tabs instead of spaces.
                           Defaults to false.
  --vue-indent-script-and-style
                           Indent script and style tags in Vue files.
                           Defaults to false.

Config options:

  --config <path>          Path to a Prettier configuration file (.prettierrc, package.json, prettier.config.js).
  --no-config              Do not look for a configuration file.
  --config-precedence <cli-override|file-override|prefer-file>
                           Define in which order config files and CLI options should be evaluated.
                           Defaults to cli-override.
  --no-editorconfig        Don't take .editorconfig into account when parsing configuration.
  --find-config-path <path>
                           Find and print the path to a configuration file for the given input file.
  --ignore-path <path>     Path to a file with patterns describing files to ignore.
                           Defaults to .prettierignore.
  --plugin <path>          Add a plugin. Multiple plugins can be passed as separate `--plugin`s.
                           Defaults to [].
  --plugin-search-dir <path>
                           Custom directory that contains prettier plugins in node_modules subdirectory.
                           Overrides default behavior when plugins are searched relatively to the location of Prettier.
                           Multiple values are accepted.
                           Defaults to [].
  --with-node-modules      Process files inside 'node_modules' directory.

Editor options:

  --cursor-offset <int>    Print (to stderr) where a cursor at the given position would move to after formatting.
                           This option cannot be used with --range-start and --range-end.
                           Defaults to -1.
  --range-end <int>        Format code ending at a given character offset (exclusive).
                           The range will extend forwards to the end of the selected statement.
                           This option cannot be used with --cursor-offset.
                           Defaults to Infinity.
  --range-start <int>      Format code starting at a given character offset.
                           The range will extend backwards to the start of the first line containing the selected statement.
                           This option cannot be used with --cursor-offset.
                           Defaults to 0.

Other options:

  --no-color               Do not colorize error messages.
  --no-error-on-unmatched-pattern
                           Prevent errors when pattern is unmatched.
  --file-info <path>       Extract the following info (as JSON) for a given file path. Reported fields:
                           * ignored (boolean) - true if file path is filtered by --ignore-path
                           * inferredParser (string | null) - name of parser inferred from file path
  -h, --help <flag>        Show CLI usage, or details about the given flag.
                           Example: --help write
  -u, --ignore-unknown     Ignore unknown files.
  --insert-pragma          Insert @format pragma into file's first docblock comment.
                           Defaults to false.
  --loglevel <silent|error|warn|log|debug>
                           What level of logs to report.
                           Defaults to log.
  --require-pragma         Require either '@prettier' or '@format' to be present in the file's first docblock comment
                           in order for it to be formatted.
                           Defaults to false.
  --stdin-filepath <path>  Path to the file to pretend that stdin comes from.
  --support-info           Print support information as JSON.
  -v, --version            Print Prettier version.

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

/area web
/kind cleanup

/assign


Upload progress for form file fields

It would be very useful to be able to se some sort of progress indicator when uploading large files using form file fields. The default behaviour could be silent, but an option to enable the progress indicator would be nice.

This would nice. I'll consider adding this once streamed uploads (#201) have been being implemented.


project Upgrade to core2.2 and then get an error

DryIoc  ver3.0.2
DryIoc.ContainerException: Dependency Microsoft.Extensions.DependencyInjection.IServiceScopeFactory as parameter "scopeFactory" reuse CurrentScopeReuse {Lifespan=100} lifespan shorter than its parent's: singleton Microsoft.Extensions.Http.DefaultHttpClientFactory {ServiceKey=DefaultKey(2)} #155

ok, will check

Until then, could try to set compat to 2_1?
services.AddMvc()
.AddControllersAsServices().SetCompatibilityVersion(CompatibilityVersion.Version_2_1)

yes,i already set；
now，i set  WithoutThrowIfDependencyHasShorterReuseLifespan this rule

@try3,
What is the version of DryIoc.Microsoft.DependencyInjection do you use?
Could you try the latest 2.2.0-preview-02 ?

I've just created an issue on your bitbucket (https://bitbucket.org/dadhi/dryioc/issues/606/ihttpclientfactory-throws-error-when-used).  Just noticed that it's duplicated here.
I will try with the preview release and report back.

Appears to be resolved in 2.2.0-preview-02

This version is pretty much stable. Non-preview will be out together with DryIoc v4.

because i used DryIoc.Internal.  so , wait release v4,then try it again

Oh, thanks for remainder, I need to restore DryIoc.Internal as well.


Update machine-learning-data-science-process-hive-tables.md

Doc review feedback

Hi @gopitk, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@bradsev
Brad -- Hi -- Would you like to review these changes and let me know if they're OK? Thanks -- Monica

Edits are fine. Please accept them Monica.


new bankin route, I'll use it for bankinnynab

A new route, I intend to use the API at bankin web services/Bridge (rienafairefr/bankinhook repo) in order to fetch transactions and then push it to ynab using fintech-to-ynab

Would you be able to write up some docs on how this works maybe?

I've modified the README.md. I'd use fintech-to-ynab as a microservice for the "push to ynab" part, I'll fetch people's transactions from their bank then push it to fintech-to-ynab. Not yet all functional but it's coming.

Oops forgot this, sorry. Do you mind if i leave this unmerged until it's feature complete?

No problem :-) Not sure I will continue pushing on this one actually, still wondering about architecture of all this and where the ynab credentials are stored etc etc. If nothing new in a let's say two weeks, you can close this.


home page loading has become too slow

The initial observation was due to enabling of Layout Inspector in Android Studio.
But keeping the issue open, as I still believe in the normal mode too, the home page can be sped up a bit


Chore: Remove the overwrite from content-type rule

⚠ This depends on https://github.com/jshttp/mime-db/pull/90.
See also: https://github.com/jshttp/mime-db/issues/77.

@alrra you have some linter issues.

you have some linter issues.

Fixed, thanks!


Update rosetta server init params

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

#72
#71
#70  👈
#63
#68
#64
#60
#61
#62
#59
feature/proof-of-stake

This stack of pull requests is managed by Graphite.

Merge activity

Feb 27, 12:03 AM EST: @lazynina started a stack merge that includes this pull request via Graphite.


Add EarTrumpet to PowerToys

Description of the new feature / enhancement
EarTrumpet (https://github.com/File-New-Project/EarTrumpet#eartrumpet) is an amazing tool that fixes lots of issues in Windows volume mixer. If this tool gets included into PowerToys, PowerToys users don't have to separately install EarTrumpet anymore.
Scenario when this would be used?
Offers more PowerToys functionality, plus easier installation for users who want to use at least one current PowerToys feature aswell as EarTrumpet on their system. Important to my workflow as I would like to have as few despersion as possible regarding Windows Tools that improve functionality so massively.
Supporting information
EarTrumpet is the 2022 Winner of the Microsoft Store Community Choice Awards Open Platform (https://blogs.windows.com/windowsdeveloper/2022/05/27/announcing-the-microsoft-store-app-awards-winners) and it is also licensed under the MIT License, so it allows for merging into PowerToys: https://github.com/File-New-Project/EarTrumpet/blob/master/LICENSE

/dup https://github.com/microsoft/PowerToys/issues/1011