I'm working with the BigQuery API on Google Cloud Platform and I've completed the Golang client library installation.
When I try to compile, I see the following errors:
[root#server ~]$ go install github.com/user/program
# github.com/user/program/handler
go/src/github.com/user/program/handler/file1.go:228: undefined:
"cloud.google.com/go/bigquery".ValueList
go/src/github.com/user/program/handler/file1.go:259: undefined:
"cloud.google.com/go/bigquery".ValueList
The offending line for 228 is:
227 for {
228 var values bigquery.ValueList
229 err := it.Next(&values)
At the top of the file I import the package, as normally
import "cloud.google.com/go/bigquery"
and have taken care to install the client library for Golang
https://cloud.google.com/bigquery/docs/reference/libraries#client-libraries-install-go
I can see that the cloud.google.com package is contained within my GOPATH and I see the ValueList type decleration inside of a file in there. It is therefore puzzling that I'm getting this error.
What's more: I can compile this fine on my Windows machine with no errors. It's only when I try to do the same thing on my CentOS VM that I run into this. Both are running go version go1.6.3.
Thank you.
#Spikey,
Hi, please make sure you've installed correct client.
Here's why:
After installing go get -u cloud.google.com/go/bigquery I see that they do not have an exported ValueList type(!). Only valuelist, i.e. unexported. Check line 39 of ~go/src/google.golang.org/cloud/bigquery/value.go
However, they do mention ValueList as an exported type in their docs(!), for example:
line 52 of ~go/src/google.golang.org/cloud/bigquery/doc.go
https://godoc.org/cloud.google.com/go/bigquery
line 164 of ~/go/src/google.golang.org/cloud/README.md
Also, ValueList is an exported type if looking directly at: https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/bigquery/value.go
So there's a confusion about installing a correct Google client.
Hope this helps!
Related
Hello to all i'm currently using the client of socket.io (https://github.com/socketio/socket.io-client-swift) with the new package manager of XCODE13 when i try to add the package using the package manager, i paste the URL of the repository(https://github.com/socketio/socket.io-client-swift) into the search bar, the package appears, then i do click into 'Add Package' button, but i get this Error (see the image):
If i use the 'Add Anyway' option in order to add the package the line import SocketIO into my view file doesn't find the package gives me an error, and i have the same result importing the package via 'Add Local' option, i get the same error.
Thank you and sorry for the English
Am i doing something wrong?
I also have problems with socket.io using Carthage in Xcode 13 and Monterey
Building scheme "SocketIO" in Socket.IO-Client-Swift.xcodeproj
Build Failed: …
…
This usually indicates that project itself failed to compile.
Edit: I fixed my issue replacing the 1200 by 1300 in the carthage workaround script
I'm running Rakudo Star 2019.03.1 on Windows 7, Cro was installed by zef. Following the Getting Started section on the Cro website, the following should work:
The cro stub command generates stub services for you, to get started
more quickly and with better defaults. Here we use it to create a
simple HTTP service, with ID hello and in the hello directory:
cro stub http hello hello
...which actually does work, it generates a lot of files for the project including the .cro.yml file, which I assume is the central description file for the service. But if I try to follow the docs and run cro run (from inside the hello directory, I assumed):
The cro run command will start your service (and automatically restart
the service if you change a file):
cro run
...the service isn't started but cro errors out:
A react block:
in sub run-services at C:\rakudo\share\perl6\site\sources\709F4B18755ADE6922C88B8C44A0930A5DDD77C9 (Cro::Tools::CLI) line 227
in sub MAIN at C:\rakudo\share\perl6\site\sources\709F4B18755ADE6922C88B8C44A0930A5DDD77C9 (Cro::Tools::CLI) line 199
in block <unit> at C:\rakudo\share\perl6\site\resources\C1E87B0F084684C12CD87240AE4C12E746174570 line 1
in sub MAIN at C:\rakudo\share\perl6\site\bin\cro line 3
in block <unit> at C:\rakudo\share\perl6\site\bin\cro line 1
Died because of the exception:
no such file or directory
in any at C:\rakudo\share/perl6/runtime/CORE.d.setting.moarvm line 1
in sub run-services at C:\rakudo\share\perl6\site\sources\709F4B18755ADE6922C88B8C44A0930A5DDD77C9 (Cro::Tools::CLI) line 227
in sub MAIN at C:\rakudo\share\perl6\site\sources\709F4B18755ADE6922C88B8C44A0930A5DDD77C9 (Cro::Tools::CLI) line 199
in block <unit> at C:\rakudo\share\perl6\site\resources\C1E87B0F084684C12CD87240AE4C12E746174570 line 1
in sub MAIN at C:\rakudo\share\perl6\site\bin\cro line 3
in block <unit> at C:\rakudo\share\perl6\site\bin\cro line 1
This error message is unfortunately not speaking to me. What do I miss?
Update
Somehow I missed this Cro github issue yesterday when googling, which is precisely what my problem was. I backlinked this question+answer in the github issue. A fix has since been merged and will be part of the next release of Cro. Props for the quick response everybody!
Original Answer
This could be resolved with the help of timotimo (Thanks!), who
suggested Cro::Tools::Runner calls perl6 instead of perl6.bat which is needed
for Windows.
pointed me to this answer which has the important bits of information regarding changing code in zef-installed modules.
So I headed over to %USERPROFILE%\.zef\store\cro-0.8.1.tar.gz\cro-0.8.1\lib\Cro\Tools and patched the executable name in line 269 of Runner.pm6. Then I went back up to %USERPROFILE%\.zef\store\cro-0.8.1.tar.gz\cro-0.8.1 and recompiled and installed the module with the following command (note the --/test to skip the tests, which take a lot of time):
C:\...\.zef\store\cro-0.8.1.tar.gz\cro-0.8.1>zef install . --force-install --/test --verbose
The following local path candidates are already installed: .
===> Installing: cro:ver<0.8.1>
===> Install [OK] for cro:ver<0.8.1>
1 bin/ script [cro] installed to:
C:\rakudo\share\perl6\site\bin
Now, cro run spews what I believe to be ANSI codes at me, but it is working :)
C:\ws\perl6\hello>cro run
←[1;32mÔûÂ Starting hello (hello)←[0m
←[32mƒöî Endpoint HTTP will be at http://localhost:20000/←[0m
←[32mƒôô hello ←[0mListening at http://localhost:20000
I am working on installing rethinkdb on my server, which is a CentOS 6.9 machine. I followed all the directions for a CentOS server as described here for CentOS 6. I got all the way to the command scl enable devtoolset-2 -- make but while building, on line 244 of 421, the line that reads build/release/obj/extproc/http_job.o I receive the error "CURLOPT_ACCEPT_ENCODING was not declared in this scope"
I don't know what this means or why the error is popping up, but I can't continue with the build process as long as that error is there.
I found an obscure article that mentions a fix for this particular error. If you go into the rethinkdb folder on the server, you can then navigate to src/extproc/http_job.cc and open that file in a text editor. You can then search for the function void set_default_opts and inside of that function is the line exc_setopt(curl_handle, CURLOPT_ACCEPT_ENCODING, "", "PROTOCOLS); If you just change CURLOPT_ACCEPT_ENCODING to `CURLOPT_ENCODING, you will be able to continue the build process. It worked for me.
I have installed Spark-1.4.0. I have also installed its R package SparkR and I am able to use it via Spark-shell and via RStudio, however, there is one difference I can not solve.
When launching the SparkR-shell
./bin/sparkR --master local[7] --packages com.databricks:spark-csv_2.10:1.0.3
I can read a .csv-file as follows
flights <- read.df(sqlContext, "data/nycflights13.csv", "com.databricks.spark.csv", header="true")
Unfortunately, when I start SparkR via RStudio (correctly setting my SPARK_HOME) I get the following error message:
15/06/16 16:18:58 ERROR RBackendHandler: load on 1 failed
Caused by: java.lang.RuntimeException: Failed to load class for data source: com.databricks.spark.csv
I know I should load com.databricks:spark-csv_2.10:1.0.3 in a way, but I have no idea how to do this. Could someone help me?
This is the right syntax (after hours of trying):
(Note - You've to focus on the first line. Notice to double-quotes)
Sys.setenv('SPARKR_SUBMIT_ARGS'='"--packages" "com.databricks:spark-csv_2.10:1.0.3" "sparkr-shell"')
library(SparkR)
library(magrittr)
# Initialize SparkContext and SQLContext
sc <- sparkR.init(appName="SparkR-Flights-example")
sqlContext <- sparkRSQL.init(sc)
# The SparkSQL context should already be created for you as sqlContext
sqlContext
# Java ref type org.apache.spark.sql.SQLContext id 1
# Load the flights CSV file using `read.df`. Note that we use the CSV reader Spark package here.
flights <- read.df(sqlContext, "nycflights13.csv", "com.databricks.spark.csv", header="true")
My colleagues and I found the solution. We have initialized the sparkContext like this:
sc <- sparkR.init(appName="SparkR-Example",sparkEnvir=list(spark.executor.memory="1g"),sparkJars="spark-csv-assembly-1.1.0.jar")
We did not find how to load a remote jar, hence we have downloaded spark-csv_2.11-1.0.3.jar. Including this one in sparkJars however does not work, since it does not find its dependencies locally. You can add a list of jars as well, but we have build an assembly jar containing all dependencies. When loading this jar, it is possible to load the .csv-file as desired:
flights <- read.df(sqlContext, "data/nycflights13.csv","com.databricks.spark.csv",header="true")
I have downloaded Spark-1.4.0, via command line I went to the directory Spark-1.4.0/R, where I have build the SparkR package located in the subdirectory pkg as follows:
R CMD build --resave-data pkg
This gives you a .tar file which you can install in RStudio (with devtools, you should be able to install the package in pkg as well).
In RStudio, you should set your path to Spark as follows:
Sys.setenv(SPARK_HOME="path_to_spark/spark-1.4.0")
.libPaths(c(file.path(Sys.getenv("SPARK_HOME"), "R", "lib"), .libPaths()))
library(SparkR)
And you should be ready to go. I can only talk from mac experience, I hope it helps?
If after you tried Pragith's solution above and you still having the issue. It is very possible the csv file you want to load is not in the current RStudio working directory. Use getwd() to check the RStudio directory and make sure the csv file is there.
I am trying to use go generate/stringer (golang.org/x/tools/cmd/stringer) to generate String() methods on enums. I have problems, which I believe, are because of slightly different format of .a packages on different systems. I have this file:
package main
import (
"math/rand"
)
//go:generate stringer -type=Foo
type Foo int;
const (
FooPrime Foo = iota
FooBis
)
func main() {
//Just use rand anywhere, otherwise we get a compiler error
rand.Seed(1)
}
Now if I run go generate example.go on my machine everything is all right: foo_string.go is created. However, on a test machine I get:
stringer: checking package: example.go:4:2: could not import math/rand (reading export data: /usr/lib64/go/pkg/linux_amd64/math/rand.a: go archive is missing __.PKGDEF)
Now, after some digging in the code I think that I get this error, because on my machine rand.a has the following header:
!<arch>
__.PKGDEF 0 0 0 644 2051
`
while on test machine it has the following header:
!<arch>
__.PKGDEF/ 0 399 399 100644 2051
`
I think that the crucial difference is slash after PKGDEFF. gcimporter refuses to process .a file, if it doesn't have __.PKGDEF header.
To check this, I edited manually gcimporter/exportdata.go and changed one of the line from this:
if name != "__.PKGDEF"
to this:
if name != "__.PKGDEF" && name != "__.PKGDEF\"
After this change (and compiling and installing everything) I was able to run go generate on example.go.
My questions are: why do I get this problem and how do I get rid of it (other then manually editing external library)?
What I can see from the spec for openSUSE's packaging they are disabling reinstallation of the standard library at updates. __.PKGDEF is a Go specific informational section, and some linker OpenSUSE has used has simply produced incompatible output.
There's nothing you can do except install a healthy Go from the official source.