Using Stack GHCi on Ubuntu Linux (Windows Subsystem Layer), I can't use any aspect of Test.QuickCheck, even though I can build it and import it. I've been using Haskell in this way for a while without issue.
The simplest failing case sums it up nicely. After successfully loading and importing QuickCheck, I try the following:
Prelude Test.QuickCheck> sample (arbitrary :: Gen Int)
I get the following:
*** Exception: clock_getres: invalid argument (Invalid argument)
This is the same error that I get in every attempted use of quickCheck, property, sample...It doesn't matter if I import QuickCheck or link it with a .cabal file. These functions all still type check, too.
"clock_getres" has something to do with Linux, so I tried using System.Random, which worked fine. Does anybody know what might be causing most of QuickCheck's functions to fail?
Related
I have written a BPF program that I can install using gobpf, i.e. using their bcc tooling. While this works alright from a main package, this breaks as soon as I move it into a package for importing it as a module.
To clarify: It works with all code in package main, but as soon as I rename the package and move the main() to cmd/command.go it stops working with go run complaining that it can't find an included lib (bcc/proto.h). Incidentally, this is the same error as I always got when running gcc on my .c file without any indication I want to use BPF (the part that gobpf did for me, until I moved its invocation to a module...).
I realize this is question very specific and sits in a weird place between Go, CGo, the way C and C++ handle includes, BPF, and bcc, but I am at a loss here.
You can check out my code here https://github.com/bwNetFlow/bpfdump if that helps. It needs bcc installed in addition to go run doing its thing. Basically:
HEAD is the modularized version that does not work (go run cmd/dump.go)
HEAD~ is my initial experiment that does work (go run bpfdump.go) (you'll get an permission error as user, which is fine as it has compiled anyways).
PS: I think it might have to do with this (rather creative?) construction of bcc/proto.h: https://github.com/iovisor/bcc/blob/master/src/cc/exported_files.cc
I'm trying to build out a simple URL shortener in Go to get familiar with the language. As part of this I'm trying to use an underlying firebase datastore which I'm authenticating against using a Service Account.
After configuring the firestore client I tried to build for the first time and started encountering the following error
$ go build
# _/C_/Users/emmao/Documents/Go/UrlShortener
2020/05/10 17:52:18 C:\Users\emmao\go\pkg\windows_amd64\github.com\golang\protobuf\ptypes.a(_go_.o): error reading symbol: EOF
After stripping back chunks of code, this is the minimum amount required to reproduce the issue:
package main
import (
"fmt"
"google.golang.org/api/option"
)
func main() {
// Use a service account
sa := option.WithCredentialsFile("path/to/serviceAccount.json")
fmt.Println(sa)
}
I'm a bit lost with it to be honest. I'm getting no syntax highlighting to indicate I've done anything wrong. And while this is an early project for me with I've built some other simple stuff which required external imports and they worked okay.
I'm using a Windows PC with Visual Studio Code as an IDE. Tried both CRLF and LF line endings. I also tried just rewriting the file again from scratch using vanilla notepad and encountered the same problem.
The extensions I have on VS code are underlining package main and showing the same error as I get on build.
Anybody encountered anything like this before?
your code is fine i test it on my mac, but it can be some outsider causes, for example: windows firewall - which blocked requests to download some go packages
see this similar issues:
https://github.com/PaloAltoNetworks/pango/issues/11#issuecomment-492211040
Go failing - expected 'package', found 'EOF'
sometimes in similar situations i got inconspicuous notifications about blocked process, etc in taskbar or small window on desktop , so you need to check your environment
I have a package collision where I get the following error:
mockgen -package=mocks -source=myproto.pb.go -destination=mocks/my_mocks.go
imported package collision: "foo" imported twice
I see one import that is obvious:
import foo "blah/blah/foo"
But I don't know where to start tracking down the duplicate import (nor where it is coming from). It seems strange to me that this is an issue as I am importing myproto.pb.go just fine, so I'm wondering if there is really an issue w/duplicate imports. Also, GoLand isn't showing any issues.
I'm hoping someone can point me in the direction of getting more information about where the duplicate import is coming form, checking if there is some issue and/or working around the issue.
This seems to be an ongoing issue. I just ran into it with it claiming "rand" was imported twice (even though my code doesn't import "rand").
The following workaround worked for me: Write down the list of interfaces in myproto.pb.go you wish to mock, and use "reflect mode" instead of "source mode"
mockgen -package=mocks -destination=mocks/my_mocks.go path.to/package/containing/myproto/pb/go [space-separated interface names]
should be equivalent to your previous invocation:
mockgen -package=mocks -source=myproto.pb.go -destination=mocks/my_mocks.go
but for some reason is more robust and does not trigger the double-import error.
When I want to use the GLM Package on Windows I get the problem
Rmath not properly installed. Please run Pkg.build("Rmath") and restart Julia.
But then the following error occurs:
Failed to precompile Rmath to ...
which then produces the error notification
Exception by Determining of "SecurityProtocol": "NULL can not
converted to the type "System.Net.SecurityProtocolType" because it is
not a possible value for enumerations values. Enter a possible value
"Ss13, Tls"
Do you know how to solve this problem?
This is more of a workaround than an actual solution to the issue.
The problem is likely a networking one (e.g., running Julia from behind a proxy server). The way to solve it is to manually download the 'zip' file whose address is given in the error when the build fails, unpack it into the 'bin' folder of Julia installation (typically something like 'C:\Users\User1\AppData\Local\[julia version]\bin'), and then run
Pkg.build("Rmath") in Julia.
I have a problem with my PyCharm. After I updated Python from 3.3.5 to 3.4, I have an annoying error in PyCharm of the following form:
from multiprocessing import Queue, Process
PyCharm underlines Queue and Process in red and shows an unresolved reference. The code actually runs fine both in the command line and inside PyCharm. Code completion seems to be broken too for these classes.
I am suspecting a problem with PYTHONPATH, but I'm not sure how to solve it.
System details: Mac OS X 10.9.2, Python 3.4 installed through Homebrew, Pycharm 3.1.1
It's not a problem with PYTHONPATH. If we look in multiprocessing\__init__.py, we see the following:
#
# Copy stuff from default context
#
globals().update((name, getattr(context._default_context, name))
for name in context._default_context.__all__)
__all__ = context._default_context.__all__
Notably there is nothing in the file that looks like Queue, Process, etc.
Now what is this context._default_context? If we look in multiprocessing\context.py, we see
class BaseContext(object):
...
def Queue(self, maxsize=0):
'''Returns a queue object'''
from .queues import Queue
return Queue(maxsize, ctx=self.get_context())
So in reality, Queue is never defined in the module itself, but rather through some dynamic code, it gets set correctly at runtime depending on the user's operating system. This is why Pycharm doesn't know that there are Queue and Process classes in the multiprocessing module.
Maybe you can file a bug report and try to get them to selectively run code to figure out these dynamic names or to make an exception here and put some workaround that tells Pycharm that there are in fact Queue/Process classes, but that seems like it would be low on their priority list. So you'll just have to live with it, probably. (In the same boat here)
I'd definitely report an issue with JetBrains if one doesn't already exist, but I would not suggest downgrading Python merely due to your IDE not interpreting an import as expected (the actual interpreter still works).
I have the same issue, simply adding # noinspection PyUnresolvedReferences above the unresolved references silences the compiler 'errors'. Of course I'd love this to be fixed and will remove the # noinspection lines once it is, but it certainly won't stop me from writing code using PyCharm and Python 3.4.
Edit: Looks like someone reported it: http://youtrack.jetbrains.com/issue/PY-12860
Edit: Reportedly fixed in build 138.913
I have had the same issue. If you are using python 3.4.4, please try this:
from queue import Queue
You can read more here: https://docs.python.org/3.4/library/queue.html