I'm trying to go get go.etcd.io/etcd/tools/benchmark.
Previously this has worked, flawlessly. However when I try to do it currently I have alternatively got no errors and I've had it fail on me with:
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/balancer_conn_wrappers.go:28:2: use of internal package google.golang.org/grpc/internal/buffer not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:49:2: use of internal package google.golang.org/grpc/internal/resolver/dns not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:50:2: use of internal package google.golang.org/grpc/internal/resolver/passthrough not allowed
The first time I ran it on a new go-1.13 installation it worked, but the following times it has failed as above.
The repo has not changed as far as I can tell in the past 8 months and I've tried on various golang versions but all so far have failed (bar the go-1.13 on that first try...).
Any assistance debugging this would be greatly appreciated!
I have both a workaround and an official fix.
The workaround:
Here I defined a go.mod which then used a previous version of the library.
The official fix:
This was fixed upstream and thus no one else should experience this.
I guess you can try by removing vendor folder from the go.etcd.io/etcd repo. Also disable the vendoring mode. It should work.
Related
So here is the situation:
I have a fork of go-ipfs. It depends on go-ipfs-config. I need to modify go-ipfs-config and make go-ipfs depend on my modified version.
I forked the go-ipfs-config made my changes and made sure to update the path to be that of my forked version as can be seen here. I confirmed that this still builds successfully by running go build
Then I updated go.mod in go-ipfs to use my modified version. I used the replace directive to signify this intention which can be seen here
This is where things gets absolutely bunkers and I am no longer sure what is going on.
When i do go mod tidy to fetch the dependency i get the following output:
go: finding module for package github.com/dadepo/go-ipfs-config
go: found github.com/dadepo/go-ipfs-config in github.com/dadepo/go-ipfs-config v0.5.3
The crazy thing is that v0.5.3 does not exist in github.com/dadepo/go-ipfs-config!
Also the following line get added to go.mod :
github.com/dadepo/go-ipfs-config v0.5.3 // indirect
Which can even be seen here
I have run commands like go clean -modcache and go clean -r etc but does not seem to fix things!
Does anybody know what I am doing wrong? And also how to achieve the goal of making my version of a project depend on another modified version of its dependency?
Ok, so this is as a result of me not being aware of couple of things going on in the Go lang toolchain.
Apparently https://proxy.golang.org is a thing! It is a service operated by google that caches modules. So If you made a release, deleted it, chances are that the version is already cached in https://proxy.golang.org. This was exactly what happened in my case. I had made a 0.5.3 release, deleted it, but it is not really gone as the Google cache already got a hold of it.
So in case you are seeing versions that should not exist. This should be the first place you check. This documentation link also sheds some more light on the proxy and how it can be tweaked.
I found this out based on the conversation I had on the issue I opened reporting this behaviour. If you are curious, you can check it out here.
I'm kinda new to using composer (but I think it is awesome) so please pardon the noob question.
Folks are requesting exports fancier than csv so I thought I'd install phpOffice excel using composer. But, the master is 'build failing' and the develop is 'build error'. An I correct in assuming the master build failed means I should not install this with composer because it won't work?
In researching this I also found phpOffice spreadsheet, but that appears to be in development still.
Any other alternatives if I cannot use phpOffice excel due to the build status issue?
Regardless of what package you are talking about, if the builds for any of the branches are failing it just means that the builds for any of the branches are failing, that's it.
The master and develop branches may be well ahead of the latest tag, and chances are the maintainers are experimenting with it, and working towards a passing build again.
If you trust the maintainers not to release broken software, then it's safe to use one of the tagged versions, so for example, run
$ composer require phpoffice/phpexcel:^1.8.1
to install the latest stable version.
Note It appears that phpoffice/phpexcel:1.8.1 has been released on 2015-05-01; quite some time has passed since. Whether or not this package works for you, then, is something you have to find out for yourself.
For reference, see:
https://packagist.org/packages/phpoffice/phpexcel
I've been trying to modify an addon to accept filtering in custom datalists.
The addon is called DatalistExtensions for Alfresco Share and can be found at https://github.com/deas/contentreich-alfresco-datalists This is supposed to be working on the version 5.*
It comes with an example. That example doesn't work at all, it gives multiple errors... I fixed the errors but it still doesn't work.
The full explanation of the behaviour can be found here:
https://forums.alfresco.com/forum/developer-discussions/alfresco-share-development/filters-custom-datalists-07052016-1320
Now the problem:
I decided to modify the add-on itself. My test was easy, I found where the filter form is created which is inside the file: contentreich-extdl.xml that is found on contentreich-alfresco-datalists-master/contentreich-extdl-share/src/main/resources/alfresco/site-data/extension/
It didn't work at all... Since it was too strange to me I decided to delete one of the built-in filters and it was still working as always which just killed my mind.
The steps I did:
Added the lines into the file.
Ran the mvn package after the change.
Copied the target files created.
What am I missing to make this changes work?
It seems that the changes I was doing were not reflected, in order to archive that you must first clean your maven target and then build the package.
mvn clean
mvn package
or even
mvn clean package
Hope this helps other people!
I downloaded go1.4.darwin-amd64-osx10.8.tar.gz and extract it on my local directory.
Based on what Installing to a custom location says I added GOROOT in env variable.
Based on what Test your installation says I created a go file.
I finally ran it and I got expected result as following screenshot.
I actually have IntelliJ v.14 however, based on this article I installed Go Language (golang.org) version 0.9.15.3 in my IntelliJ Idea.
I created a Go project and during creation it asked me to add GO SDK. I gave it ~/Desktop/go/sdk however it wasn't able to recognise it. I got this error in Event Log:
14:03:02 IllegalArgumentException: Argument for #NotNull parameter
'virtualFile' of
com/intellij/openapi/projectRoots/impl/ProjectRootContainerImpl.addRoot
must not be null
Any idea how IntelliJ Idea is able to recognize it would be appreciated. Thanks.
Please consider using one of the alpha releases for 0.9.16. I believe that alpha7 could be the more stable one rather than alpha9. You can get them from GitHub releases
The v1.0.0-alpha0 branch is, as the name implies, an alpha release and it's in the early stages of development, that's why there's no release done yet for it as well.
P.S. I'm one of the contributors to the plugin.
Does not allow to use SDK placed in /usr/local/go (perfectly valid and recent SDK) under Mac Yosemite.
Google App Engine does not recognise last valid GAE GO SDK either.
~Desktop/go/sdk doesn't seems a valid path (as it refers to the homedir of the 'Desktop' user): ~/Desktop/go/sdk should work better.
As long as you see in that ~/Desktop/go/sdk folders the subfolders 'api', 'bin', 'blog', ..., that should be the right one for the GO SDK expected by the "golang support plugin".
Some issues exist with that plugin and IntelliJ 14: issues 1169, PR 1172 (fixed for for 1.0.0-alpha).
The other approach is to recompile and install that plugin.
The end result of specifying the Go SDK path should look like:
So I have been attempting to incorporate the ability to both fetch and clone repo's using rugged. I have tried the following
repo.fetch("origin")
and this
remote = Rugged::Remote.lookup(repo, remote_name)
remote.connect(:fetch)
also this
subject.clone(url, local_path)
All of these return with the error
Rugged::NetworkError:
This transport isn't implemented. Sorry
Now, ordinarily, I would take the error as it not being implemented yet. However, having seen questions asked like this, and this. I question the accuracy of that error.
I have ensured that libgit2 and libssh2 are both installed on the my local system running this code.
I have also looked through the source attempting to find where this error is generated, and was unable to locate it. To me, this does not make sense, since the error is not as descriptive to point to specifically where it is failing.
My question is, is this intended behavior? I would think it is not, based on the questions and answers I found regarding this. In which case, does someone know if this is a common issue? Any help is appreciated.
so I discovered the issue, in that that libgit2 and libssh2 where not properly linking at installation of rugged using bundler. I was pointed in this general direction by this answer.
By running the following command
bundle install --path bundle/
The conflict was resolved.